당신이 잊고 있었던 git 명령어들 (그리고 왜 AI 워크플로우가 이들을 다시 중요하게 만드는가)

대부분의 개발자들은 git commit, git push, git stash는 알고 있습니다. 하지만 그 아래에는 아무도 방문하지 않는 층이 통째로 존재합니다.

직접 시도해 보세요: git-archaeology-lab을 클론(clone)하고, bash setup.sh를 실행하면 이 글에 소개된 모든 명령어에 대해 작동하는 실습 과제가 준비되어 있습니다.

git worktree — 하나의 저장소, 여러 개의 체크아웃 (checkouts)

이 명령어는 범죄 수준으로 과소 사용되고 있습니다. 기본적으로 git은 클론(clone)당 정확히 하나의 작업 디렉토리(working directory)만 가질 수 있게 합니다. git worktree는 그 제약을 깨뜨립니다.

이제 당신은 두 개의 완전히 독립적인 작업 디렉토리를 가질 수 있습니다. 동일한 저장소(repo)를 사용하지만 브랜치(branch)는 다릅니다. 스태싱(stashing)도, 브랜치 전환(switching)도, 컨텍스트(context) 손실도 필요 없습니다.

다시 주목받는 이유: AI 코딩 에이전트(AI coding agents) 때문입니다. 한 브랜치에서 Claude Code나 Cursor를 실행 중인데 다른 브랜치의 핫픽스(hotfix)를 검토해야 할 때, 세션 중간에 브랜치를 전환하면 모든 흐름이 깨집니다. git worktree를 사용하면 두 작업이 동시에 존재할 수 있습니다. 각 에이전트는 자신만의 트리(tree)를 가집니다. 충돌(collision)이 발생하지 않습니다.

git bisect — 이진 탐색 (binary search)으로 원인 찾기

버그가 발생했습니다. 3주 전에는 이 버그가 없었다는 사실은 알고 있습니다. 그 사이에는 200개의 커밋(commit)이 있습니다. git bisect는 이 과정을 약 8번의 시도로 줄여줍니다.

진정한 강력함은 git bisect run에 있습니다. 종료 코드(exit code)가 0(good) 또는 0이 아닌 값(bad)을 반환하는 어떤 명령이든 전달하세요. 전체 테스트 스위트(test suite), curl 헬스 체크(health check), grep 등 회귀(regression)를 감지할 수 있는 무엇이든 신탁(oracle) 역할을 할 수 있습니다. git은 수동 작업 없이 스스로 범인이 되는 커밋을 찾아냅니다.

git rerere — 같은 충돌을 두 번 해결하지 마세요

rerere는 Reuse Recorded Resolution의 약자입니다.

전역(globally)으로 한 번만 활성화해 두면, 충돌이 조용히 스스로 해결되는 것을 발견할 때까지 잊고 있어도 됩니다. 이 기능의 이점은 수십 개의 커밋에 걸쳐 동일한 충돌이 나타나는 긴 대화형 리베이스(interactive rebases) 과정에서 가장 명확하게 드러납니다.

git log -S — 곡괭이 (the pickaxe)

특정 문자열이 언제 추가되었거나 제거되었는지 알고 싶을 때 사용합니다. 어떤 커밋이 파일을 건드렸는지가 아니라, 어떤 커밋이 정확히 이 텍스트를 변경했는지를 찾아냅니다.

-S는 커밋 메시지가 아닌 diff content (차이점 내용)를 검색합니다. 파일 내에서 특정 문자열의 개수가 변경된(추가되거나 삭제된) 커밋을 찾아냅니다. 심지어 HEAD에서 비밀 정보(secret)가 삭제된 후라도, git log -S는 해당 정보를 처음 도입한 커밋을 찾아낼 수 있습니다. 삭제만으로는 충분하지 않습니다. 자격 증명(credential)을 교체하십시오.

git notes — 커밋을 건드리지 않고 주석 달기

커밋은 불변(immutable)입니다. 하지만 때로는 히스토리를 다시 쓰지 않고도, 사후에 JIRA 티켓, 테스트 결과, 배포 타임스탬프와 같은 정보를 커밋에 첨부하고 싶을 때가 있습니다.

Notes는 별도의 ref (refs/notes/commits)에 저장되며 커밋 해시(commit hash)를 변경하지 않습니다. 히스토리를 건드리지 않으면서 빌드 메타데이터로 커밋에 주석을 달고자 하는 CI/CD 파이프라인에 매우 유용합니다.

git range-diff — 차이점의 차이점 (diff of diffs)

브랜치를 리베이스(rebase)했습니다. 리베이스 과정에서 패치(patch)들이 조용히 망가지지 않았는지 확인하고 싶습니다. git range-diff는 두 개의 커밋 시퀀스를 패치 단위로 비교합니다.

=는 패치들이 동일함을 의미합니다. !는 무언가 어긋났음을 의미하며, git은 인라인으로 차이점의 차이점(diff-of-diffs)을 보여줍니다. 코드 리뷰 도구들은 이를 보여주지 않지만, 오직 range-diff만이 이를 수행할 수 있습니다.

git sparse-checkout — 필요한 것만 체크아웃하기

40개의 패키지가 있는 모노레포(Mono-repo)에서 단 두 개의 패키지만 작업하시나요? Sparse checkout을 사용하면 git에게 특정 경로만 실체화(materialize)하도록 명령할 수 있습니다.

그 외의 모든 것은 git 히스토리에는 존재하지만 디스크에는 나타나지 않습니다. 에디터는 더 빨라지고, find 명령어도 정상적으로 작동합니다. AI 워크플로우에서 sparse checkout은 에이전트(agent)가 보는 표면적(surface area)을 줄여줍니다. 파일 수가 적을수록 grep 속도가 빨라지고, 컨텍스트 윈도우(context window)가 슬림해지며, 관리하지 않는 패키지를 실수로 수정하는 일도 방지할 수 있습니다.

git commit --fixup + git rebase --autosquash

커밋을 하고 자신의 diff를 검토하던 중, 세 번째 이전 커밋에서 오타를 발견했습니다. 고통스러운 대화형 리베이스(interactive rebase)를 거치지 않고도 깔끔하게 해결할 수 있는 방법이 있습니다.

--fixup은 git commit --amend에 대한 정직한 대안입니다. Amend는 HEAD를 다시 쓰지만, fixup은 이전의 어떤 커밋이라도 대상으로 삼으며 리베이스가 이를 squash(합치기)할 때까지 감사 가능한 흔적(auditable trail)을 남깁니다.

git blame -C — 이동된 코드 추적하기

표준 git blame은 코드가 파일 간에 이동할 때 제대로 작동하지 않습니다. -C 옵션은 git에게 복사되거나 이동된 콘텐츠를 감지하고 이를 올바르게 할당하도록 지시합니다.

함수를 파일 간에 이동할 때마다, 복사 감지(copy-detection) blame은 단순한 이동자가 아닌, _누가 이 로직이 이렇게 작동해야 한다고 결정했는지_에 대한 진정한 계보(lineage)를 제공합니다.

git bundle — git 스니커넷 (sneakernet)

네트워크가 없습니다. 에어갭(Air-gapped) 상태의 머신입니다. USB 드라이브가 있습니다. git bundle은 전체 저장소(또는 특정 커밋 범위)를 어디든 가지고 다닐 수 있는 단일 파일로 패키징합니다.

이 번들(bundle)은 유효한 git 원격 저장소(remote)입니다. 번들로부터 클론(clone)할 수 있고, 페치(fetch)할 수 있으며, 검사할 수 있습니다. 그저 파일일 뿐입니다.

Claude Code에 추론 능력(reasoning skill) 로드하기

명령어를 아는 것과