worktree는 repo 하나에 checkout을 여러 개 둬
feature/x를 작업하는데 main의 긴급 bug를 고쳐야 하고, 진행 중 코드는 아직 빌드되지 않아 stash하기도 어렵다고 해보자. 옛 해법은 repo를 한 번 더 clone하는 것이었고 현대적인 해법은 git worktree야. 여러 branch의 checkout이 하나의 .git/을 공유해 같은 commit, hook, config를 쓰면서 작업 트리만 나란히 둬.
git worktree add ../repo-hotfix hotfix/login은 ../repo-hotfix에 hotfix/login을 checkout한 새 worktree를 만들어. 원래 ./repo는 여전히 feature/x에 있어. branch를 계속 switch하는 대신 directory를 오가는 셈이지. .git/을 공유하므로 어느 worktree에서 만든 commit도 다른 쪽에서 곧바로 보여. git worktree list는 checkout을 나열하고 git worktree remove ../repo-hotfix는 끝난 작업 공간을 치워.
쓸모가 큰 경우는 셋이야. 진행 중 feature를 건드리지 않고 hotfix를 고쳐 ship하기, 옛 commit의 worktree에서 긴 test를 돌리는 동안 원래 worktree에서 계속 개발하기, git worktree add ../repo-pr-142 pr/142로 main checkout을 흔들지 않고 동료 PR을 검토하기야.
함정도 둘 있어. 같은 branch를 worktree 둘에 동시에 checkout할 수 없고 Git이 거부해. 읽기 전용 모습만 원한다면 git worktree add --detach를 써. 또 worktree마다 전체 작업 트리가 있어 disk를 쓰지만 별도의 .git/objects/는 없어. 큰 repo에서는 secondary worktree의 partial clone이나 sparse checkout으로 공간을 아낄 수 있어. Vercel 같은 플랫폼에서는 각 worktree를 독립적으로 배포하는 CI 흐름에도 잘 맞아.