Git worktree — 스태시 중단, 병렬 작업 시작

Source: Dev.to

위에 제공된 소스 링크 외에 번역할 텍스트가 포함되어 있지 않습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.

소개: 브랜치 전환의 고통 😤

Git을 오래 사용해 본 사람이라면 이 순간을 경험했을 것입니다:

기능 구현에 깊이 빠져 있습니다. 파일은 절반만 작성됐고, 테스트는 (고의로) 실패하고 있습니다.

그때 갑자기:

• “이 메인에 급히 핫픽스 하나만 빨리 고쳐줄 수 있어?”
• “이 PR을 로컬에서 리뷰해줄래?”

그래서 우리는 이렇게 움직입니다:

git status
git stash
git checkout main

나중에…

git checkout feature/my-work
git stash pop
# 💥 충돌

맥락이 사라지고, 흐름이 끊기며, 자신감이 흔들립니다.

Git은 수년간 이 문제를 해결할 수 있는 방법을 제공해 왔지만—많은 개발자들이 아직 사용하지 않고 있습니다: git worktree.

git worktree란? 🌳

git worktree는 같은 저장소의 여러 브랜치를 동시에 각각의 디렉터리에서 체크아웃할 수 있게 해줍니다.

핵심 아이디어

• 하나의 Git 저장소
• 여러 작업 디렉터리
• 각 디렉터리는 자체적으로 체크아웃된 브랜치를 가짐

저장소를 다시 클론하는 것이 아닙니다. 히스토리를 복사하는 것이 아닙니다. 같은 저장소에 대한 또 다른 뷰를 만드는 것입니다.

고통 없이 병렬 체크아웃.

git worktree가 작동하는 방식 (개념적으로) 🧠

A normal Git repo:

• One .git directory (history, objects, refs)
• One working directory (your files)

일반적인 Git 저장소:

• 하나의 .git 디렉터리 (히스토리, 객체, refs)
• 하나의 작업 디렉터리 (당신의 파일)

With worktrees:

• Still one .git
• Multiple working directories

worktree를 사용할 때:

• 여전히 하나의 .git
• 여러 작업 디렉터리

Each worktree:

• Is on a different branch
• Has its own files
• Is completely isolated from the others

각 worktree:

• 서로 다른 브랜치에 있음
• 자체 파일을 가짐
• 다른 worktree와 완전히 격리됨

What’s shared

• Git history, commits, objects

공유되는 것

• Git 히스토리, 커밋, 객체

What’s isolated

• Checked‑out branch
• Working files
• Uncommitted changes

격리되는 것

• 체크아웃된 브랜치
• 작업 파일
• 커밋되지 않은 변경 사항

Multiple terminals, multiple folders, same repo.

여러 터미널, 여러 폴더, 동일한 저장소.

git worktree vs 전통적인 브랜치 전환 ⚖️

전통적인 워크플로우

• 하나의 작업 디렉터리
• 한 번에 하나의 브랜치
• 자주 스태시 사용
• 컨텍스트를 잃기 쉬움

git worktree와 함께

• 스태시 불필요
• 더러운 작업 트리 문제 없음
• 잘못된 브랜치에 실수로 변경하지 않음
• 진정한 병렬 작업

요약: 브랜치 전환 → 순차 작업; worktree → 병렬 작업.

실용적인 사용 사례 (실제 워크플로) 🚀

기능 개발 + 핫픽스 🚑

당신은 feature/auth 브랜치에서 작업 중이며, main에 프로덕션 버그가 발생했습니다.

git worktree add ../repo-hotfix main

이제 다음과 같이 됩니다:

repo/           → feature/auth
repo-hotfix/    → main

버그를 수정하고, 커밋하고, 푸시하세요 — 기능 작업은 건드리지 않은 채로.

로컬에서 PR 검토하기 🔍

팀원의 브랜치를 확인하세요:

git worktree add ../repo-pr-123 pr/some-feature

편집기에서 열고, 테스트를 실행하고, 자유롭게 탐색하세요. 메인 작업은 그대로 유지됩니다.

실험 및 스파이크 🧪

위험한 리팩터링을 시도하고 있나요?

git worktree add ../repo-experiment experiment/refactor-auth

작동하면 → 유지하고, 작동하지 않으면 → 워크트리를 삭제하세요. 두려움 제로, 혼란 제로.

릴리스 또는 QA 검증 🧪

안정적인 브랜치를 체크아웃 상태로 유지하세요:

git worktree add ../repo-release release/1.4

빌드를 실행하고, 수정 사항을 검증하며, 다른 곳에서 정상적인 기능 작업을 진행하면서 QA를 검증하세요.

단계별: git worktree 사용 🛠️

새 워크트리 만들기

주 레포에서:

git worktree add ../my-repo-hotfix main

• 새 디렉터리를 생성합니다
• 그곳에 main을 체크아웃합니다
• 동일한 Git 레포와 연결합니다

새 브랜치를 가진 워크트리 만들기

git worktree add -b feature/payments ../my-repo-payments

새 작업을 시작하기에 적합합니다.

모든 워크트리 목록 보기

git worktree list

예시 출력:

/path/repo              abc123  feature/auth
/path/repo-hotfix       def456  main
/path/repo-experiment   ghi789  experiment/refactor

일반적으로 작업하기

워크트리 안에서는 일반적인 명령을 실행할 수 있습니다:

• git status
• git commit
• git push

모든 것이 일반 레포와 동일하게 동작합니다.

워크트리 제거 (정리 🧹)

작업이 끝났을 때:

git worktree remove ../my-repo-hotfix

• Git 메타데이터를 정리합니다
• 워크트리를 안전하게 제거합니다

⚠️ 폴더를 수동으로 삭제하지 마세요; 항상 git worktree remove를 사용하세요.

Common pitfalls & gotchas ⚠️

• One branch = one worktree – 같은 브랜치를 두 번 체크아웃할 수 없습니다.
• 폴더를 수동으로 삭제하는 대신 항상 git worktree remove를 사용하세요.
• .env, node_modules 또는 빌드 출력물과 같은 공유 파일은 격리가 필요할 수 있습니다(예: .env.local 또는 워크트리별 설정).
• IDE가 여러 프로젝트를 열 수 있는데, 이는 보통 버그가 아니라 기능입니다.

git worktree가 빛을 발할 때 — 그리고 그렇지 않을 때 ✨

빛을 발할 때

• 기능과 핫픽스를 동시에 다룰 때
• 자주 중단될 때
• 대형 레포지토리에서 작업할 때
• 명확한 정신적 구분을 원할 때

그렇지 않을 수도 있는 경우

• 레포가 아주 작을 때
• 한 번에 하나의 작업만 할 때
• Git 기본을 아직 배우는 중일 때

결론 및 요점 🎯

git worktree는 틈새 기능이 아니라 생산성을 배가시키는 도구입니다.

핵심 요점

• 컨텍스트 전환을 위해 스태시하는 것을 멈추세요
• 동시에 여러 브랜치에서 작업하세요
• 흐름을 유지하고, 정신적 안정을 유지하세요
• 깔끔하고 명시적이며 병렬적인 작업을 가능하게 하세요

일단 사용해 보면, 지속적인 스태시로 돌아가는 것이… 고통스럽게 느껴집니다. 다음 중단 상황에서 git worktree를 시도해 보고 워크플로가 어떻게 바뀌는지 확인해 보세요.