RSS 줄리아 에반스 노트

RSS 줄리아 에반스

줄리아 에반스의 개인 웹사이트는 기술, 소프트웨어 엔지니어링 및 학습에 초점을 맞춘 통찰력 있고 흥미로운 콘텐츠의 보물창고입니다. 에반스, 저명한 소프트웨어 엔지니어는 그녀의 플랫폼을 통해 그녀의 광범위한 지식을 통해 자세한 블로그 포스트, 매력적인 일러스트레이션 및 개인적인 일화들을 공유합니다. 그녀의 글쓰기 스타일은 접근성이 좋고 유머러스하여 심지어 복잡한 기술 주제라도 넓은 청중에게 접근 가능하게 합니다. 웹사이트에는 리눅스 내부 구조, 프로그래밍 언어 및 디버깅 기술에 대한 다양한 주제의 기사들이 포함되어 있습니다. 에반스의 기술에 대한 열정과 복잡한 개념을 분명하게 설명하는 그녀의 능력은 그녀의 작품을 통해 빛나며, 독자들을 교육하고 영감을 주고 있습니다. 당신이 경험이 있는 개발자이든 코딩 여정을 막 시작했든, 줄리아 에반스의 웹사이트는 소프트웨어 엔지니어링 세계에 대한 새로운 관점과 가치 있는 통찰을 제공합니다.

노트 스레드

저자는 Node.js에 의존하지 않고 프론트엔드 JavaScript를 작성하는 것을 목표로 합니다. 직면한 중요한 과제는 프론트엔드 코드에 대한 효과적인 테스트 방법의 부족입니다. Playwright를 사용한 이전 시도는 느리고 Node.js가 필요하다고 판단되었습니다. 이를 해결하기 위해 저자는 Alex Chan의 미니멀리스트 인브라우저 단위 테스트 프레임워크에 대한 작업을 참고하여 테스트를 브라우저 탭 내에서 직접 실행하는 것을 탐구했습니다. Chan의 접근 방식은 단위 테스트에 중점을 두었지만, 저자는 Node.js 빌드 프로세스 없이 Vue 컴포넌트에 대한 엔드투엔드 통합 테스트를 수행하고자 했습니다.저자는 테스트 프레임워크로 QUnit을 사용했으며, 디버깅을 위한 "rerun test" 버튼을 높이 평가했습니다. 이 과정에는 Vue 컴포넌트를 전역적으로 노출하여 설정하고, 보이지 않는 페이지 외부 div에 렌더링하는 mountComponent 함수를 만드는 것이 포함되었습니다. Fixture 데이터는 전용 엔드포인트로 POST 요청을 보내 데이터베이스를 재설정하여 관리되었습니다. 그런 다음 기본적인 테스트는 컴포넌트를 렌더링하고 해당 내용을 어설션했습니다.비동기 작업 완료를 기다리는 것이 주요 문제로 대두되었고, 이는 waitFor() 함수의 개발로 이어졌습니다. 기다릴 올바른 요소나 조건을 식별하는 것이 어려웠으며, 더 나은 안정성을 위해 애플리케이션을 리팩토링하라는 제안을 유도했습니다. 저자는 또한 요소 식별을 위해 CSS 클래스를 추가하는 것을 실험했으며, Testing Library와 같은 라이브러리가 더 접근 가능한 접근 방식을 권장한다고 언급했습니다.폼 처리는 단순히 값을 설정하는 것만으로는 충분하지 않았기 때문에 어려움을 겪었습니다. 관련 DOM 이벤트를 디스패치해야 했습니다. 이는 UI 테스트 라이브러리가 이러한 작업을 단순화할 수 있는 이유를 강조했습니다. 테스트 커버리지는 Chrome의 내장 개발자 도구를 사용하여 부분적으로 평가되었지만, 번들링된 JavaScript와 함께 작동하려면 특정 구성 및 작업이 필요했습니다.학습 곡선에도 불구하고 저자는 이 경험을 즐겁게 여겼으며 자신의 프론트엔드 프로젝트에 대한 자신감 있는 테스트 스위트를 구축하는 것에 대해 낙관적인 태도를 보였습니다. 또한 브라우저 전용 실행과 호환되는 UMD 빌드를 제공하는 Testing Library와 같은 라이브러리를 더 탐구하고 브라우저 우선 테스트를 CI 환경에 통합하는 방법을 고민하고 있습니다.
저자는 "터미널의 비밀 규칙"이라는 새로운 쟁을 출시했습니다. 이 쟁은 터미널이 어떻게 작동하는지 설명하고 터미널 프로그램 사용에 대한 팁과 요령을 제공합니다. 저자는 20년 동안 매일 터미널을 사용했지만 여전히 작동 방식에 대해 많은 오해가 있었습니다. 터미널에는 화살표 키를 이동할 때도 있고 그렇지 않을 때도 있는 등 여러 가지 사소한 불일치가 있습니다. 터미널이 작동하는 "규칙"은 여러 다른 소프트웨어 조각으로 구성되어 있기 때문에 이해하기 어렵습니다. 이 쟁은 터미널의 네 가지 구성 요소(셸, 터미널 에뮬레이터, 프로그램 및 TTY 드라이버)가 어떻게 함께 작동하는지 설명하고 터미널에서 작동하는 방식에 대한 핵심 규칙을 제공합니다. 저자는 셸을 구성하는 방법과 이스케이프 코드를 이해하는 방법을 포함하여 쟁을 쓰는 동안 놀라운 양을 배웠습니다. 이 쟁은 PDF 또는 인쇄 버전으로 구매할 수 있으며, 저자의 모든 쟁을 15개 묶음으로 구매할 수도 있습니다. 저자는 PuTTY를 작성한 기술 검토자와 터미널의 내부 작동을 이해하는 사람을 포함하여 많은 사람들의 도움을 받았습니다. 인쇄 버전은 8월에 배송될 예정이며, 저자는 인쇄할 수량을 결정하기 위해 주문을 기다려야 합니다. 이 쟁은 12달러이며, 저자는 독자들이 터미널을 더 잘 이해하고 사용하는 데 도움이 되기를 바랍니다.
ANSI 이스케이프 코드는 터미널 사용성을 향상시키는 데 사용되지만, 완전히 표준화되지 않아 신뢰성 문제를 야기합니다. 저자는 터미널을 연구하는 과정에서 ANSI 이스케이프 코드에 대해 알게 되었고, 이를 둘러싼 표준을 이해하고자 했습니다. 이스케이프 코드는 터미널 에뮬레이터가 프로그램과 통신하는 데 사용되며, 키 입력 및 마우스 움직임을 위한 입력 코드와 텍스트 색상 변경 및 커서 이동과 같은 작업을 위한 출력 코드의 두 가지 유형이 있습니다. 1976년에 발표된 ECMA-48 표준은 이스케이프 코드의 일반적인 형식과 일부 특정 코드를 정의하지만, 완전한 것은 아닙니다. Xterm 제어 시퀀스는 터미널 에뮬레이터에서 널리 구현되었지만 공식 표준은 아닌 또 다른 이스케이프 코드 집합입니다. ncurses에서 관리하는 terminfo 데이터베이스는 다양한 터미널에 대한 이스케이프 코드를 저장하며, 일부 프로그램은 이를 사용하여 어떤 코드를 사용할지 결정합니다. 그러나 일부 프로그램은 terminfo를 사용하지 않고 대부분의 터미널 에뮬레이터에서 작동하는 "단일 공통 집합"의 이스케이프 코드를 직접 코딩합니다. 이 공통 집합이 무엇인지에 대한 명확한 합의는 없지만, VT100, ECMA-48 및 xterm의 코드가 포함될 가능성이 높습니다. 이러한 어려움에도 불구하고 ANSI 이스케이프 코드의 표준화는 더 풍부한 터미널 환경을 가져올 수 있으며, 저자는 더 명확한 표준 환경이 터미널 에뮬레이터 및 응용 프로그램의 혁신을 촉진할 수 있기를 기대합니다.
PATH에 디렉터리를 추가하려면 먼저 사용 중인 셸을 확인해야 하며, 이를 확인하는 방법은 ps -p $$ -o pid,comm= 명령어를 실행하는 것입니다. 리눅스의 기본 셸은 bash이며, Mac OS의 기본 셸은 zsh입니다.다음으로, 셸의 구성 파일을 찾을 필요가 있습니다. 일반적으로 zsh의 경우는 ~/.zshrc, bash의 경우는 ~/.bashrc, fish의 경우는 ~/.config/fish/config.fish입니다. 그러나 bash의 구성 파일은 세 가지 옵션이 있을 수 있습니다. ~/.bashrc, ~/.bash_profile, ~/.profile 중 하나를 사용 중일 수 있으며, 실제로 사용 중인 파일을 확인해야 할 수 있습니다.셸의 구성 파일을 찾은 후, PATH에 추가할 디렉터리를 확인해야 합니다. 이를 확인하는 방법은 프로그램의 설치 지침을 확인하거나, 설치 프로그램에 특정 명령어를 사용하는 것입니다. 예를 들어 Node/npm의 경우는 npm config get prefix 명령어를 사용할 수 있습니다.정확한 디렉터리를 찾은 후, 해당 디렉터리에서 프로그램을 실행해보기 위해 확인해야 합니다.다음으로, 셸 구성 파일을 편집하여 PATH에 디렉터리를 추가해야 합니다. 이 구문은 셸에 따라 다르며, bash와 zsh의 경우는 export PATH=$PATH:~/directory, fish의 경우는 set PATH $PATH ~/directory입니다.마지막으로, 셸을 다시 시작하여 변경 사항을 적용해야 합니다. 프로그램이 여전히 작동하지 않는 경우, PATH의 시작 부분에 디렉터리를 추가하거나, IDE 또는 cron 작업에서 프로그램을 실행하는 경우에는 PATH에 디렉터리를 추가하는 다른 방법을 사용해야 할 수 있습니다.추가적으로, 일부 설치 프로그램은 PATH를 자동으로 설정하는 스크립트를 제공할 수 있습니다. 이를 셸 구성 파일에 추가할 수 있습니다. 그러나 PATH에 디렉터리를 수동으로 추가하는 것이 더 좋을 수 있습니다.
글쓴이는 복사/붙여넣기에 대한 다중 라인 지원, 무한 쉘 기록, 24비트 컬러 지원과 같은 기능이 포함된 "현대적" 터미널 경험을 구성하는 요인을 숙고합니다. 이러한 경험을 달성하는 것이 쉘, 터미널 에뮬레이터, 텍스트 편집기를 포함한 관련된 여러 구성 요소로 인해 어려울 수 있다는 점을 인정합니다. 현대적 터미널 경험을 달성하기 위한 글쓴이의 개인적 접근 방식에는 24비트 컬러를 지원하는 터미널 에뮬레이터의 fish shell, 사용자 지정 구성이 적용된 neovim이 포함됩니다. 많은 시간을 구성에 할애하고 싶지 않은 사람들에게 글쓴이는 oh-my-zsh와 함께 fish나 zsh를 사용하고 24비트 컬러를 지원하는 터미널 에뮬레이터와 micro나 helix와 같은 텍스트 편집기를 사용할 것을 제안합니다. 그러나 글쓴이는 이러한 옵션에도 불구하고 쉘, 텍스트 편집기, 개별 애플리케이션에 문제가 있어 현대적 터미널 경험을 얻는 것이 어려울 수 있다는 점에 유의합니다. bash나 zsh와 같은 일반적인 쉘은 만족스러운 경험을 제공하기 위해 사용자 지정이 필요하므로 쉘은 특히 문제가 될 수 있습니다. 텍스트 편집기도 문제가 될 수 있으며 vim이나 emacs와 같은 옵션에는 상당한 구성이 필요하지만 nano는 제한된 경험을 제공합니다. 글쓴이는 개별 애플리케이션도 문제를 일으킬 수 있고, 이러한 문제를 디버깅하는 데 시간이 많이 걸릴 수 있다는 점에 유의합니다. 궁극적으로 글쓴이는 현대적 터미널 경험을 달성하려면 인내, 실험, 그리고 작은 변경을 하고 새로운 도구와 구성에 적응하려는 의지가 필요하다고 결론 내립니다.
"버퍼링은 터미널 프로그램에서 성능을 개선하기 위해 출력을 그룹화하는 일반적인 방법입니다. 일정한 크기 임계값에 도달할 때까지 출력을 버퍼링합니다. 이렇게 하면 파이프에 데이터가 느리게 추가되는 경우 문제가 발생할 수 있습니다. 프로그램이 출력을 버퍼링하고 이를 작성하지 않을 수 있습니다.Grep 및 유사한 프로그램은 파이프에 쓰일 때 블록 버퍼링을 기본적으로 사용하지만 터미널에 쓰일 때는 라인 버퍼링을 사용합니다. 따라서 "tail -f /some/log/file | grep thing1 | grep thing2" 명령어가 출력을 표시하지 않는 이유를 설명합니다.grep, sed, awk, tcpdump, jq와 같은 명령어는 출력을 버퍼링합니다. 반면 tail, cat, tee와 같은 명령어는 버퍼링하지 않습니다.C, Python, Ruby, Perl과 같은 프로그래밍 언어도 출력을 버퍼링할 수 있습니다. 이러한 버퍼링을 비활성화하는 다양한 방법이 있습니다.파이프에서 Ctrl-C를 누르면 프로그램의 출력 버퍼가 손실될 수 있습니다. 신호가 버퍼가 플러시되기 전에 수신되기 때문입니다.파일로 리디렉션할 때도 버퍼링이 발생하지만 일반적으로 예상대로 작동합니다. 프로그램이 종료되기 전에 버퍼의 내용이 작성됩니다.버퍼링을 피하려면 프로그램이 빠르게 끝나는지 확인하거나 grep에서 "--line-buffered" 플래그를 사용할 수 있습니다. 명령어를 awk로 다시 작성하거나 stdbuf를 사용하여 프로그램이 터미널에 쓰이는 것처럼 작동하게 할 수도 있습니다. unbuffer를 사용하여 프로그램이 일관된 동작을 수행하게 할 수도 있습니다.이deal한 솔루션은 특정 상황에 따라 다르며 unbuffer가 일관된 동작을 제공하는 신뢰할 수 있는 선택입니다.버퍼링은 일반적으로 문제가 되지 않지만 파이프에 데이터가 느리게 추가되는 경우 발생할 수 있습니다. 버퍼링을 비활성화하는 환경 변수가 있으면 유용할 수 있지만, 설계 및 구현에는 도전이 있습니다."
저자는 자신의 사이트에 새로운 섹션을 만들었습니다. "TIL" (오늘 배운 것)이라고 불리는 이 섹션은 저자가 소셜 미디어에 게시하는 흥미로운 도구와 사실들을 저장하는 곳입니다. 목표는 전체 블로그 게시물을 작성하지 않고도 이러한 정보를 저장할 수 있는 곳을 만들기 위함입니다. 저자는 종종 마스토돈과 블루스카이에 "멋진 것들"을 게시하지만, 이러한 것들을 추적할 곳이 없었습니다. 이 새로운 섹션은 사이먼 윌리슨의 TIL 블로그에서 영감을 받았지만, 저자의 게시물은 훨씬 짧습니다. 저자는 TIL 섹션을 위한 새로운 폴더를 만들었고, 사용자 정의 스타일링을 추가하고, 별도의 RSS 피드를 설정했습니다. TIL 섹션은 주로 저자의 자신의 용도로, 유용한 링크와 도구를 추적하는 방법입니다. 저자는 이 섹션을 몇 주 동안 사용해 왔고, 잘 작동하는 것을 발견했습니다. 저자는 "POSSE" (자신의 사이트에 게시하고, 다른 곳에 공유)라는 아이디어를 좋아하지만, 자신이 자신의 사이트에 유지하고 싶은 콘텐츠의 특정 카테고리를 식별하는 것이 더 쉽다고 생각합니다. 저자는 블로그 게시물과 만화책에 대한 이메일 목록과 RSS 피드를 가지고 있으며, TIL 게시물의 요약을 자신의 메일링 목록에 추가할 수 있습니다. 저자는 일부 콘텐츠를 일시적(ephemeral)로 유지하는 것을 선호합니다. 예를 들어, 투표와 농담은 일시적이며, 특정 카테고리의 콘텐츠만 보관합니다.
저자는 터미널에서 제어 코드의 개념을 탐구합니다. 예를 들어 Ctrl-A, Ctrl-C, Ctrl-W와 같은 코드들이 어떻게 작동하는지에 대해 설명합니다. ASCII 제어 문자는 33개가 있으며, 운영 체제의 터미널 드라이버가 처리하는 코드, 실제 키 누름에 해당하는 코드, readline에서 사용하는 코드로 분류할 수 있습니다. 저자는 이러한 코드들이 실제 구조 없이 유기적으로 진화했기 때문에 어느 코드가 어느 카테고리에 속하는지에 대한 실제 구조가 없음을 지적합니다. 제어 코드는 총 33개밖에 없으므로 Ctrl-1을 키보드 단축키로 사용하고 싶다면 의미가 없습니다. 왜냐하면 1을 누르는 것과 동일하기 때문입니다. 저자는 Ctrl+Shift+C도 제어 코드가 아니며, 터미널 에뮬레이터에 따라 행동이 다르다고 지적합니다. ASCII 제어 코드의 공식 이름은 실제로 사용되지 않습니다. 왜냐하면 원래 텔레그래프 기계를 위해 정의되었고, 이후 다른 용도로 재사용되었기 때문입니다. 저자는 Ctrl-M과 Ctrl-I를 키보드 단축키로 사용하는 것이 어려움을 느낍니다. 왜냐하면 Enter와 Tab 키와 동일하기 때문입니다. 저자는 다양한 키 조합을 눌렀을 때 보내지는 제어 코드를 확인하는 파이썬 스크립트를 제공합니다. 저자는 Ctrl-W와 Ctrl-U와 같은 일부 제어 코드가 터미널이 표준 모드인지 비표준 모드인지에 따라 다르게 처리될 수 있음을 지적합니다. 마지막으로 저자는 제어 코드와 관련된 많은 예외 사항과 충돌이 있으며, 이러한 모든 정보가 실제로는 유용하지 않을 수 있음을 인정합니다.
저자, 캐주얼한 Go 프로그래머, 할당 중 구조체가 복사되는 방식에 대한 기본적인 오해를 드러내는 버그를 마주쳤다. 구조체가 할당 중 복사되는 것이 아니라 참조되는 것임을 알지 못했기 때문이었다. 이러한 행동은 예상치 못한 결과를 초래했는데, 변수에 할당된 후 구조체를 수정했을 때였다. 저자는 다른 언어에서 변수가 일반적으로 참조로 전달되는 경험이 있었기 때문에 이러한 행동에 놀랐다. 함수 인수에서 pass-by-value와 pass-by-reference의 차이를 이해했지만 변수 할당에 이를 확장하지 않았다. 저자는 또한 Go에서 하위 슬라이스가 원래 슬라이스와 동일한 백킹 배열을 공유하는 것을 발견했는데, 이는 하위 슬라이스에 추가하는 것이 원래 슬라이스를 의도치 않게 수정할 수 있음을 의미한다. 저자는 또한 Go 메서드에서 값 수신자와 포인터 수신자 사이의 차이를 분명하게 이해했는데, 메서드가 호출된 구조체를 변경해야 하는 경우 포인터 수신자가 필요함을 알게 되었다. 저자는 "100 Go Mistakes" 리소스를 그들의 분명하고 간결한 형식으로 인해 칭찬했는데, 이는 저자가 Go의 일반적인 함정들을 쉽게 확인하고 배울 수 있도록 했다. 마지막으로 저자는 "Go by Example," "go.dev/play," 및 "staticcheck"와 "golangci-lint"와 같은 정적 분석 도구를 포함하여 다른 가치 있는 Go 리소스들을 나열했다.
Git에서 '현재 분기'라는 개념은 가까이 들여다보면 모호성을 보여준다. Git 용어집에서 .git/HEAD 파일의 내용으로 정의되지만, 'git status' 출력, 마지막으로 체크아웃한 분기, 쉘 프롬프트 등 다른 해석들도 있다. 이러한 해석들은 일반적으로 일치하지만, 분리된 HEAD 상태, 태그 체크아웃, 리베이스 중인 상황 등에서 다르다. 예를 들어 태그를 체크아웃하면 .git/HEAD에는 커밋 ID가 저장되지만, 'git status'는 사용자 편의를 위해 태그 이름을 표시한다. 리베이스 중에는 'git status'가 리베이스 상태를 강조표시하지만, 쉘 프롬프트는 원래의 분기를 나타낸다. 심지어 'git init'에서도 '현재 분기'가 명시적으로 체크아웃하지 않고도 자동으로 설정된다. bare 저장소에서는 'git status'와 'git checkout'이 작동하지 않아 추가적인 복잡성이 발생한다. 이러한 불일치점들은 '현재 분기'를 엄격하게 정의하는 제약을 보여주고, 문맥에 따른 이해의 중요성을 강조한다. '현재 분기'가 새로운 커밋의 대상이라고 일반적으로 생각되지만, 리베이스 중에는 최종적으로 원래의 분기에 커밋이 랜딩하는 경우에는 그러하지 않다. '현재 분기'가 Git 작업의 문맥을 나타낸다고 생각하는 것은 타당하지만, bare 저장소에서 'git status'가 다르게 작동하는 등 불일치점들이 있다. 최종적으로 '현재 분기'의 모호성을 이해하려면 .git/HEAD, 'git status' 출력, 마지막 체크아웃 액션 등 다양한 지표를 고려해야 한다.
- 풀 처리: 업스트림 브랜치가 분기할 때 병합 커밋을 피하기 위해 pull.ff only 또는 pull.rebase true를 사용합니다. - 병합 충돌 가독성: merge.conflictstyle zdiff3은 병합 충돌의 가시성을 높이기 위해 중간에 원래 코드를 표시합니다. - 자동 커밋 수정: rebase.autosquash true는 리베이스 중에 fixup! 커밋을 대상과 결합합니다. - 자동 스테이싱: rebase.autostash true는 리베이스 전에 및 후에 git stash를 실행합니다. - 푸시 자동화: push.default current 또는 push.default simple은 현재 브랜치를 일치하는 원격 브랜치에 푸시합니다. push.autoSetupRemote true는 첫 번째 푸시에 추적을 설정합니다. - 기본 브랜치: init.defaultBranch main은 새로운 저장소에서 main 브랜치를 생성하여 master 브랜치 대신 사용합니다. - 커밋 메시지 개선: commit.verbose true은 커밋 메시지 편집기에서 커밋 차이를 표시합니다. - 충돌 해결 자동화: rerere.enabled true은 병합 충돌 해결을 기억하고 자동화합니다. - 오타 수정: help.autocorrect 10은 Git이 오타 수정을 실행하는 데 일정한 지연을 허용합니다. - 차이점 시각화: core.pager delta는 구문 강조 표시하는 차이점 뷰어를 사용합니다. diff.algorithm histogram은 함수 재정렬 가시성을 개선합니다. - 글로벌 Gitignore: core.excludesfile은 글로벌 gitignore 파일을 지정합니다. - 별도의 Git 구성: includeIf는 개인 및 직장 저장소에 대한 다른 구성들을 허용합니다. - 데이터 손상 방지: transfer.fsckobjects 및 관련 설정은 데이터 손상을 감지하고 방지합니다. - 기타 주목할만한 옵션: 블라임 무시, 브랜치 정렬, 색상 설정, 에디터 선택, 커밋 정리, 코어 설정, 차이점 도구, 병합 설정, 태그 추적 푸시, 리베이스 안전, 로그 날짜 형식 등입니다.
저자는 초기에 git cherry-pick을 단순한 패치 적용으로 오해했지만, 실제로는 "3-way merge"라는 더 정교한 프로세스를 통해 작동하는 것을 알게 되었다. 패치 방법으로 병합 충돌을 해결하려고 했을 때 실패한 경험에서 이러한 오해가 발생했는데, 예상했던 git cherry-pick의 동작 방식과는 달랐다. 이를 조사하는 과정에서 git의 소스 코드를 살펴보게 되었고, cherry-pick이 3-way merge를 사용하는 것을 알게 되었다. 당시 저자는 3-way merge라는 개념에 익숙하지 않았다. 이러한 개념은 두 파일을 병합하는 데 사용되는 방식으로, 이를 통해 파일의 원래 버전(베이스)과 비교하여 병합을 수행하게 된다. 이러한 개념은 패치 적용에까지 확장되어, 커밋 전후의 파일 버전과 현재 파일이 병합에 사용되는 세 가지 버전을 구성하게 된다. Cherry-pick, rebase, revert 모두 이 3-way merge 전략을 사용하지만, 베이스와 타겟 버전의 순서와 해석 방식에서 차이가 있다. 저자는 이 기술을 "3-way 패치"라고 명명하여, 병합에 대한 더 많은 문맥을 제공하는 장점을 강조했다. 일반적인 패치를 처리하는 git apply도 --3way 플래그를 제공하여 3-way 병합을 수행할 수 있다. 이러한 탐험은 git에서 패치를 적용하는 데 사용되는 3-way 병합의 지혜를 강조하며, 사용자들이 익숙한 "패치 적용" 개념에 머물러 있으면서도 다양한 작업을 수행할 수 있는 통일된 접근 방식을 제공한다. 저자는 git의 병합 메커니즘의 복잡성을 인정하면서, 재귀적 병합 및 다중 병합 알고리즘과 같은 개념을 암시하고, 더 많은 탐험을 위해 "Building Git" 책을 추천했다. 마지막으로 저자는 git의 패치 메커니즘의 우아한 설계에 대한 감사를 표하며, 그 직관성과 효율성을 칭찬했다.