복잡한 기능을 한창 개발하고 있는데 긴급 메시지가 도착합니다. 프로덕션 서버가 다운됐어요.

지금 당장 핫픽스가 필요합니다. 패닉에 빠지죠.

작업하던 파일들은 여기저기 널려 있습니다. 지저분한 작업 내용을 Git Stash로 임시 저장하시겠습니까?

아니면 서둘러 WIP 커밋을 남기시나요?

최악의 경우 버그 하나를 고치자고 프로젝트 전체를 새로 복제하기도 합니다.

이제 그런 방식을 더 이상 사용하지 않을 수 있습니다. 더 나은 방법이 있습니다.

오늘 우리는 Git Worktree를 배울 겁니다. 마치 슈퍼파워처럼 컨텍스트 전환에 고통 없이 여러 브랜치에서 동시에 작업하게 해 주는 기술이죠.

Git Worktree가 무엇인지 개념부터 알아보겠습니다.

원래 Git 저장소는 화면에 보이는 것처럼 단 하나의 작업 디렉터리만 가집니다.

브랜치를 체크아웃하면 여러분의 파일들은 그 브랜치의 내용으로 전부 바뀌게 되죠.

다른 브랜치를 보려면 현재 작업을 멈추고 다시 파일을 바꿔야만 합니다.

하지만 깃 워크트리는 이 규칙을 완전히 우회합니다.

화면에 강조된 것처럼 동일한 깃 저장소에 여러 개의 독립된 작업 디렉터리를 가질 수 있게 해 줍니다.

이해를 돕기 위해 도서관에 비유해 보겠습니다.

여러분의 깃 저장소는 모든 책의 원본을 보관하는 도서관 본관 즉 깃 폴더와 같습니다.

화면 왼쪽에 일반적인 깃 방식은 하나의 책상만 가진 것과 같습니다.

다른 책, 즉 다른 브랜치를 읽고 싶으면 지금 보던 책을 덮고 책장에 다시 넣은 뒤 새 책을 가져와야 하죠.

반면 오른쪽에 깃 워크트리는 여러 개의 책상을 가진 것과 같습니다.

첫 번째 책상에 피처 개발 책을 펼쳐 두고 그냥 두 번째 책상으로 걸어가 긴급 수정 책을 바로 펼칠 수 있습니다.

두 책상 모두 같은 도서관을 공유하지만 물리적으로는 완전히 분리된 공간인 셈입니다.

그럼 어떻게 이런 일이 가능할까요?

워크트리를 생성하면 깃은 폴더를 만듭니다.

이 세 폴더는 화면의 아키텍처처럼 원본 저장소의 히스토리, 즉 깃 폴더에 연결됩니다.

가장 중요한 점은 프로젝트 전체를 또 복제하는 것이 아니라는 점입니다.

중앙의 두뇌 역할을 하는 깃 폴더는 공유하고 작업할 수 있는 깨끗한 공간만 새로 내어 주는 것이죠.

덕분에 디스크 공간을 엄청나게 절약할 수 있습니다. 폴더 구조로 보면 이렇습니다.

여러분의 프로젝트 루트 폴더가 있습니다. 그 안에는 공유되는 두뇌인 깃 폴더가 있죠.

그리고 여러분이 원래 작업하던 메인 워킹 디렉터리가 있습니다.

여기는 메인 브랜치가 체크아웃되어 있다고 가정합시다.

워크트리를 생성하면 화면에 보이는 것처럼 프로젝트 폴더와는 별개의 위치에 새로운 폴더가 생깁니다.

이 핫픽스 폴더는 물리적으로는 완전히 다른 곳에 있지만 논리적으로는 원래의 깃을 함께 사용하고 있는 것입니다.

자, 이제 실제 개발 시나리오를 통해 직접 실습해 보겠습니다.

여러분은 메인 폴더에서 새로운 피처를 개발하고 있는데 즉시 버그를 수정해야 하는 상황입니다.

먼저 1단계 현재 상태를 확인합니다.

프로젝트 폴더에 있겠죠. 터미널에서 `git status` 명령을 실행합니다.

결과를 보시죠. 피처 로그인 브랜치에 있고 아직 커밋하지 않은 수정 사항들이 보입니다.

로그인과 스타일 파일이 빨갛게 표시되어 있네요.

우리는 이 지저분한 상태를 전혀 건드리고 싶지 않습니다.

2단계는 새로운 워크트리를 만드는 것입니다.

명령어는 화면 상단에 보이는 것처럼 `git worktree add` 뒤에 경로와 브랜치 이름을 적어 줍니다.

터미널에서 `git worktree add`를 사용해 상위 폴더에 `hotfix` 폴더 그리고 `main`이라고 입력합시다.

이 명령어는 현재 폴더 바깥에 `hotfix` 폴더라는 새 디렉터리를 만들고 그 안에 `main` 브랜치를 체크아웃하라는 의미입니다.

여기서 상위 폴더를 써서 프로젝트 폴더 바깥에 만드는 것이 핵심입니다.

작업 공간을 깨끗하게 유지해 주죠.

3단계는 새로 만든 책상으로 자리를 옮기는 것입니다.

아주 간단합니다. 그냥 디렉터리를 변경하면 됩니다.

상위 폴더인 핫픽스 폴더로 이동합니다. 들어가서 ls 명령으로 파일 목록을 확인해 보세요.

보시는 것처럼 메인 브랜치에 깨끗한 파일들이 그대로 보입니다.

여러분이 작업하던 지저분한 피처 로그인 브랜치의 변경 사항들은 원래 폴더에 안전하게 그대로 있습니다.

이제 4단계 실제 작업을 할 차례입니다.

여기서는 평소와 똑같이 작업하면 됩니다. 먼저 Git 체크아웃 명령으로 버그 수정을 위한 새 브랜치를 만듭니다.

그다음 필요한 코드 수정 작업을 하고 Git 커밋으로 변경 사항을 저장하고 마지막으로 Git 푸시를 통해 원격 저장소에 변경 사항을 올립니다.

워크트리라고 해서 특별한 워크플로우가 있는 것이 아닙니다.

똑같습니다. 자, 급한 불은 껐습니다.

이제 원래 하던 피처 개발 작업으로 돌아갈 시간입니다.

다시 `cd` 명령어를 사용해서 원래 프로젝트 폴더로 돌아옵니다. 그리고 `git status`를 실행해 봅시다.

놀랍죠? 모든 것이 여러분이 자리를 비우기 전과 정확히 똑같은 상태입니다.

`git stash pop` 같은 명령어로 임시 저장했던 내용을 다시 불러오는 복잡한 과정이 전혀 필요 없습니다.

워크트리는 매우 강력하지만 몇 가지 흔히 저지르는 실수들이 있습니다. 이 점들을 알아두면 훨씬 원활하게 사용할 수 있습니다.

첫 번째 실수는 워크트리를 프로젝트 폴더 안에 만드는 것입니다.

화면에 보이는 것처럼 현재 디렉터리 내에 경로를 지정하면 안 됩니다.

이렇게 하면 원래 프로젝트의 Git이 이 새 폴더를 추적하지 않았던 디렉터리로 감지해서 `git status`가 지저분해집니다.

가장 좋은 방법은 항상 상위 폴더를 사용해서 프로젝트 폴더 바깥, 즉 나란한 위치에 워크트리를 만드는 것입니다.

두 번째 실수는 이미 체크아웃된 브랜치 오류를 만나는 것입니다. Git은 매우 똑똑해서 두 개의 다른 폴더가 동시에 정확히 같은 브랜치를 수정하는 위험한 상황을 막아 줍니다.

만약 메인 프로젝트에서 메인 브랜치를 보고 있는데 새 워크트리에도 메인을 체크아웃하려고 하면 화면 상단처럼 치명적인 오류가 발생합니다.

해결책은 간단합니다. 만약 메인 브랜치의 내용을 보기만 할 거라면 화면 하단의 해결책처럼 명령어 끝에 디태치 옵션을 붙여 주면 됩니다.

이렇게 하면 특정 브랜치에 묶이지 않은 임시 상태로 워크트리가 생성됩니다.

마지막으로 의존성 관리 문제입니다.

기억하세요. 새로 만든 워크트리는 완전히 깨끗한 새 디렉터리입니다.

이것은 원래 프로젝트의 노드 모듈이나 파이썬의 venv 같은 의존성 폴더를 공유하지 않는다는 의미입니다.

따라서 새 워크트리 폴더로 이동했다면 가장 먼저 npm install이나 pip install 같은 명령어를 다시 실행해서 의존성을 설치해 주어야 합니다.

오늘 배운 내용을 요약해 보겠습니다. 첫째, Git Worktree는 여러 브랜치를 각기 다른 폴더에서 동시에 체크아웃할 수 있게 해 줍니다.

둘째, 모든 워크트리가 하나의 깃 스토리를 공유하기 때문에 프로젝트를 새로 복제하는 것보다 디스크 공간을 훨씬 절약할 수 있습니다.

셋째, 이 기능은 주요 피처를 개발하는 동시에 긴급 버그를 수정하거나 동료의 코드를 리뷰하는 등 멀티태스킹이 필요할 때 정말 완벽합니다.

마지막으로 가장 중요한 규칙입니다. 워크트리 폴더는 항상 메인 프로젝트 디렉터리의 외부에 생성해야 한다는 점을 잊지 마십시오.

이제 워크트리를 만드는 법은 알게 되었습니다. 그럼 다 쓴 워크트리는 어떻게 정리할까요?

다음 시간에는 워크트리 관리 방법에 대해 알아보겠습니다.

생성된 워크트리 목록을 보고 제대로 삭제하고 작업 공간을 깨끗하게 정리하는 방법을 다룰 겁니다.

지난 영상에서는 여러 작업을 동시에 처리하기 위해 새 워크트리를 만드는 법을 배웠습니다.

하지만 정리하지 않고 계속 만들기만 하면 하드 드라이브와 Git 저장소는 금세 엉망이 되겠죠.

오늘은 이 워크트리들을 관리하는 법을 배울 겁니다.

어떤 작업들이 열려 있는지 보고 제대로 닫고 실수로 폴더를 삭제했을 때 대처하는 방법까지 알아봅시다.

워크트리는 마치 책상 위에 여러 프로젝트 서류를 펼쳐 놓는 것과 같습니다.

매우 편리하지만 일이 끝나면 서류를 잘 정리해서 서랍에 넣어야 책상이 깨끗해지죠.

이번 시간에는 바로 그 정리하는 방법을 배웁니다.

즉 워크트리를 조회하고 삭제하고 혹시 모를 실수를 바로 잡는 방법입니다.

관리법을 배우기 전에 워크트리가 어떻게 원본 저장소와 연결되는지 잠깐 살펴봅시다.

git` 폴더가 있죠. 이 안에 모든 커밋 기록이 저장됩니다. 그런데 워크트리를 만들면 메인 저장소의 `.

git` 폴더에 `worktrees` 폴더 안에 해당 워크트리의 메타데이터가 생성됩니다.

그리고 워크트리 폴더에는 폴더가 아닌 파일로 된 깃이 생깁니다.

이게 핵심입니다. 이 깃 파일 안에는 원본 저장소에 워크트리 메타데이터 경로가 적혀 있어서 둘이 서로 연결됩니다.

이 연결 구조를 기억해 두세요.

나중에 복구할 때 왜 그런 방법을 쓰는지 이해하는 데 도움이 됩니다.

자, 이제 본격적으로 워크트리를 관리하는 방법을 알아봅시다.

먼저 내 책상 위에 어떤 서류들이 펼쳐져 있는지 확인부터 해야겠죠.

현재 저장소에 어떤 워크트리들이 연결되어 있는지 보려면 화면에 보이는 이 명령어를 사용합니다.

`git worktree list`라고 입력하면 됩니다. 아주 간단하죠?

명령어를 실행하면 이런 결과가 나옵니다. 첫 번째 줄은 항상 원래의 메인 워크트리입니다.

이건 워크트리 명령어로 제거할 수 없는 기본 작업 공간이죠.

Git Worktree로 여러 피처 동시에 개발하기 | AI 코딩 시대의 필수 스킬

코딩맥스 CodingMax

Git Worktree는 하나의 Git 저장소에 여러 독립된 작업 디렉터리를 가질 수 있게 하여, 여러 브랜치에서 동시에 작업할 때 컨텍스트 전환 없이 효율적인 병렬 개발을 가능하게 합니다.

Git Worktree를 효과적으로 관리하려면 `git worktree list`로 현재 워크트리를 확인하고, `git worktree remove`로 작업이 끝난 워크트리를 안전하게 삭제하며, 실수로 폴더를 지웠을 경우 `git worktree prune`으로 Git 기록을 정리해야 합니다.

전문가들은 Bare Repository 전략을 사용하여 Git 데이터베이스와 실제 작업 파일을 완전히 분리하고, 이를 통해 메인 폴더를 깔끔하게 유지하며 PR 리뷰나 긴급 버그 수정 시 일회용 작업 환경을 구축하여 개발 효율성을 극대화합니다.

복잡한 기능을 개발하던 중 긴급 핫픽스가 필요할 때, 기존 방식으로는 **작업 중인 파일들을 임시 저장하거나 서둘러 커밋하는 등 불편함**이 많았습니다. 심지어 프로젝트 전체를 새로 복제하는 최악의 상황도 발생할 수 있었습니다. 하지만 Git Worktree를 활용하면 이러한 문제점 없이 여러 브랜치에서 동시에 작업할 수 있습니다.

기존 Git은 단 하나의 작업 디렉터리만 가지며, 브랜치를 체크아웃하면 파일 내용이 모두 변경됩니다. 하지만 **Git Worktree는 동일한 Git 저장소에 여러 개의 독립된 작업 디렉터리를 가질 수 있게 해 줍니다.** 이는 도서관의 여러 책상에 비유할 수 있으며, 각 책상에서 다른 책(브랜치)을 펼쳐 놓고 동시에 작업하는 것과 같습니다.

Worktree를 생성하면 Git은 새로운 폴더를 만들고, 이 폴더는 원본 저장소의 `.git` 폴더(히스토리)에 연결됩니다. **가장 중요한 점은 프로젝트 전체를 또 복제하는 것이 아니라, 중앙의 `.git` 폴더를 공유하고 깨끗한 작업 공간만 새로 내어준다는 것**입니다. 덕분에 디스크 공간을 크게 절약할 수 있습니다.

새로운 피처를 개발하던 중 즉시 버그를 수정해야 하는 시나리오를 통해 Worktree 사용법을 실습할 수 있습니다. 먼저 `git status`로 현재 작업 상태를 확인하고, **`git worktree add <경로> <브랜치 이름>` 명령어를 사용해 새로운 Worktree를 생성**합니다. 이때, 작업 공간을 깔끔하게 유지하기 위해 상위 폴더에 Worktree를 만드는 것이 핵심입니다.

새로 만든 Worktree 폴더로 이동한 후에는 평소와 똑같이 작업하면 됩니다. 버그 수정을 위한 새 브랜치를 만들고, 코드 수정 후 커밋 및 푸시하는 과정을 거칩니다. **Worktree를 사용한다고 해서 특별한 워크플로우가 필요한 것은 아닙니다.** 긴급 작업이 끝나면 `cd` 명령어로 원래 프로젝트 폴더로 돌아오고, 기존 작업 상태는 그대로 유지됩니다. `git stash pop` 같은 복잡한 과정 없이 즉시 복귀할 수 있습니다.

Worktree를 프로젝트 폴더 안에 만들면 원래 프로젝트의 Git이 새 폴더를 추적하지 않는 디렉터리로 감지하여 `git status`가 지저분해집니다. 따라서 **항상 상위 폴더를 사용하여 프로젝트 폴더 바깥, 즉 나란한 위치에 Worktree를 생성**하는 것이 좋습니다.

Git은 **두 개의 다른 폴더가 동시에 정확히 같은 브랜치를 수정하는 위험한 상황을 막아줍니다.** 만약 메인 브랜치가 체크아웃된 상태에서 새 Worktree에도 메인 브랜치를 체크아웃하려고 하면 오류가 발생합니다. 단순히 메인 브랜치의 내용을 보기만 할 경우에는 명령어 끝에 `--detach` 옵션을 붙여 임시 상태로 Worktree를 생성할 수 있습니다.

새로 만든 Worktree는 완전히 깨끗한 새 디렉터리이므로, **원본 프로젝트의 노드 모듈이나 파이썬의 `venv` 같은 의존성 폴더를 공유하지 않습니다.** 따라서 새 Worktree 폴더로 이동했다면 `npm install`이나 `pip install` 같은 명령어를 다시 실행하여 의존성을 설치해야 합니다.

현재 저장소에 연결된 Worktree 목록을 확인하려면 `git worktree list` 명령어를 사용합니다. 이 명령어는 각 Worktree의 폴더 경로, 최신 커밋 해시, 브랜치 이름을 보여줍니다. **첫 번째 줄은 항상 원래의 메인 Worktree이며, 이는 Worktree 명령어로 제거할 수 없는 기본 작업 공간입니다.**

Worktree 작업이 끝났다면 **`git worktree remove <워크트리 경로>` 명령어를 사용하여 안전하게 삭제**해야 합니다. 단순히 `rm` 명령어로 폴더를 삭제하면 Git 기록에 유령 Worktree가 남게 됩니다. `git worktree remove`는 저장하지 않은 변경 사항이 있을 경우 작업을 중단시키는 안전 장치가 있어 데이터를 보호해 줍니다.

만약 `rm` 명령어로 Worktree 폴더를 삭제하여 Git에 유령 Worktree가 남았다면, **`git worktree prune` 명령어를 사용하여 유효하지 않은 항목을 Git의 기록에서 지울 수 있습니다.** `prune`은 '가지치기'라는 뜻으로 불필요한 기록들을 정리해 줍니다. 단, `prune` 실행 시 스테이징된 변경 사항은 복구가 불가능해지니 주의해야 합니다.

워크트리 `remove`는 물리적인 작업 공간(폴더)을 삭제하는 것이고, `git branch -D`는 작업 내역의 흐름을 가리키는 브랜치 포인터를 삭제하는 것입니다. **Worktree를 제거한다고 해서 브랜치가 사라지는 것은 아니므로, 브랜치까지 삭제하려면 별도로 `git branch -D` 명령을 실행해야 합니다.**

Worktree 폴더를 직접 삭제하고 복구할 내용이 없다면, **`git worktree prune`으로 유령 워크트리 메타데이터를 삭제한 후 `git worktree add` 명령으로 같은 브랜치를 체크아웃한 새 Worktree를 재생성**하면 됩니다. 이는 복구가 아닌 재생성이며, 커밋하지 않은 변경 사항은 영구적으로 사라집니다.

폴더는 삭제했지만 아직 푸시를 실행하지 않았고 `git add`로 스테이징해 둔 변경 사항이 있는 경우, **실제 복구가 가능합니다.** 이는 Git이 스테이징된 변경 사항을 메인 저장소의 `.git` 폴더에 저장하기 때문입니다. 삭제된 폴더와 같은 이름으로 폴더를 만들고, 그 안에 원본 저장소의 Worktree 메타데이터 위치를 연결하는 `.git` 파일을 생성하면 됩니다. 이 방법은 `prune`을 실행하기 전에만 가능합니다.

워크트리와 연결된 브랜치까지 실수로 삭제하여 오류가 발생했다면, **`git reflog`를 사용하여 삭제된 브랜치의 마지막 커밋 해시를 찾아 브랜치를 다시 만들 수 있습니다.** `reflog`는 Git이 모든 헤드 이동 기록을 보관하는 일종의 블랙박스 역할을 합니다.

Worktree 폴더를 다른 위치로 옮겨 Git이 찾지 못하는 경우, **`git worktree repair` 명령을 사용합니다.** 이동한 Worktree 폴더 안에서 실행하거나 메인 저장소에서 새 경로를 지정하여 실행하면 손상되거나 오래된 Worktree 관리 파일들을 복구해 줍니다.

전문가를 위한 Bare Repository 전략

숙련된 개발자들은 `.bare` 폴더를 만들어 **Git 데이터베이스와 실제 작업 파일을 완전히 분리하는 Bare Repository 전략을 사용**합니다. 이를 통해 깔끔한 프로젝트 구조를 유지하고, `npm install` 대기 시간 단축, 브랜치 전환 시 혼란 방지 등 여러 이점을 얻을 수 있습니다.

Bare Repository를 설정하려면, 먼저 프로젝트 루트 폴더를 생성하고, **`git clone --bare <원격 저장소 주소> .bare` 명령으로 작업 파일 없이 순수한 Git 데이터베이스만 다운로드**합니다. 이어서 `git worktree add --track -b main main` 명령으로 첫 번째 작업 폴더를 만들어 연결합니다. 이때 `git config core.bare`는 `.bare` 폴더 안에서 명령을 실행하는 것처럼 동작하게 합니다.

동료의 풀 리퀘스트(PR)를 리뷰할 때, 기존 방식은 작업 스태시, 브랜치 전환, 의존성 설치 등 복잡한 과정을 거쳐야 했습니다. 하지만 Bare Repository 전략에서는 **`git fetch origin pull/<PR 번호>/head:<로컬 브랜치 이름>` 명령으로 PR을 가져와 로컬 브랜치로 만들고, `git worktree add <새 폴더 이름> <로컬 브랜치 이름>` 명령으로 일회용 리뷰 환경을 생성**할 수 있습니다.

Worktree 관련 명령어 (`list`, `remove`, `prune` 등)는 Bare Repository에서도 동일하게 적용됩니다. 단, **명령어 앞에 `git -C .bare`를 붙여 Bare 데이터베이스를 기준으로 명령을 실행하도록 알려줘야 합니다.** 이렇게 하면 프로젝트 루트 폴더에서 전체 브랜치 목록을 한눈에 보거나 새 브랜치를 만들 수 있습니다.

**절대 Bare Repository의 루트, 즉 `.bare` 폴더가 있는 곳에서는 `git pull`을 실행하면 안 됩니다.** `pull`은 코드를 가져와 현재 작업 공간에 병합하려는 명령어인데, `.bare` 폴더는 코드를 담을 몸이 없는 순수한 데이터베이스이기 때문입니다. 올바른 방법은 먼저 `git fetch`로 데이터베이스만 업데이트하고, 실제 Worktree 폴더로 들어가서 `git pull`을 실행하는 것입니다.

Bare Repository 전략을 사용하면 **세 가지 작업을 동시에 진행해야 할 때 터미널 창 세 개를 열고 각 Worktree에서 독립된 포트로 서버를 실행**할 수 있습니다. 각 Worktree는 독립된 환경에서 작동하므로 스태시나 충돌 없이 효율적인 병렬 개발이 가능합니다. 단, 포트 번호는 수동으로 지정해야 하며, 각 Worktree마다 `npm install`을 별도로 실행해야 합니다.

레거시 버전의 버그를 수정해야 하는 경우에도 Worktree가 유용합니다. **새로운 앱은 Node.js 24를 사용하고, 옛날 버전은 Node.js 14에서만 돌아가는 상황에서, 레거시 Worktree를 하나 만들고 그 안에서만 Node.js 14 버전을 사용하도록 설정**할 수 있습니다. 원래의 메인 폴더는 아무런 영향을 받지 않고 안전하게 유지됩니다.

Worktree는 디스크 공간과 시간 비용을 수반합니다. React나 Next 같은 웹 프로젝트의 `node_modules` 폴더 용량은 상당하며, 여러 Worktree를 만들면 디스크 공간을 많이 차지합니다. 또한 **대형 프로젝트에서 `npm install`은 몇 분 이상 걸릴 수 있어, 여러 Worktree를 만들면 설치 시간이 누적되어 PR 리뷰가 예상보다 느려질 수 있습니다.**

이러한 비용을 줄이는 방법으로는 **PNPM과 같은 최신 패키지 매니저를 사용하여 디스크 사용량과 설치 시간을 줄이거나, 코드 리뷰가 끝난 Worktree를 즉시 `git worktree remove`로 삭제하여 깔끔하게 정리하는 습관**을 들이는 것이 있습니다. Worktree는 장기적인 피처 브랜치가 많은 대형 프로젝트에 가장 적합한 방식입니다.

Git Worktree를 활용하면 여러 브랜치에서 동시에 작업할 때 기존 방식과 비교하여 어떤 이점들이 있나요?

Git Worktree 사용 시 발생할 수 있는 흔한 실수 세 가지는 무엇이며, 각 실수에 대한 해결책은 무엇인가요?

Bare Repository 전략은 일반적인 Git 저장소 구조와 어떻게 다르며, 어떤 상황에서 이 전략을 사용하는 것이 가장 효과적인가요?

워크트리 폴더를 실수로 삭제했을 때 `prune` 명령 실행 여부에 따라 복구 방법이 어떻게 달라지는지 구체적으로 설명해주세요.

Git Worktree 사용의 단점으로는 무엇이 있으며, 이러한 단점을 완화하기 위한 방법은 무엇인가요?

복잡한 기능 개발 중 긴급 핫픽스 상황에서 기존 Git Stash나 WIP 커밋, 프로젝트 재복제 방식의 불편함을 언급.

Git Worktree가 컨텍스트 전환 없이 여러 브랜치에서 동시에 작업할 수 있게 해주는 기술임을 소개.

기존 Git 저장소는 하나의 작업 디렉터리만 가지며, 브랜치 전환 시 파일이 변경되는 반면, Git Worktree는 여러 독립된 작업 디렉터리를 가질 수 있음을 설명.

도서관 비유를 통해 Worktree는 여러 책상에서 동시에 다른 책(브랜치)을 볼 수 있는 것과 같다고 설명.

프로젝트 전체를 복제하는 것이 아니라, 중앙의 Git 폴더를 공유하고 깨끗한 작업 공간만 새로 제공하여 디스크 공간을 절약한다고 강조.

Git Worktree 실습 시나리오 및 사용법

피처 개발 중 긴급 버그 수정 상황을 예로 들어 `git worktree add` 명령어를 사용하여 새로운 워크트리를 생성하는 방법을 설명.

워크트리를 프로젝트 폴더 바깥에 생성하여 작업 공간을 깔끔하게 유지하는 것이 중요하다고 언급.

새로 생성된 워크트리에서 일반 Git 워크플로우와 동일하게 작업하고, 완료 후 원래 작업으로 쉽게 돌아갈 수 있음을 시연.

Git Worktree 사용 시 흔히 저지르는 실수와 해결책

첫 번째 실수: 워크트리를 프로젝트 폴더 안에 생성하여 `git status`가 지저분해지는 문제.

두 번째 실수: 이미 체크아웃된 브랜치를 새 워크트리에 다시 체크아웃하려 할 때 발생하는 오류와 `detach` 옵션을 사용한 해결책.

세 번째 실수: 의존성 관리 문제로, 새 워크트리에서는 `npm install` 등 의존성을 별도로 설치해야 함을 설명.

Git Worktree 요약 및 다음 내용 예고

여러 브랜치 동시 체크아웃, 디스크 공간 절약, 멀티태스킹에 완벽함, 그리고 워크트리 폴더는 항상 메인 프로젝트 외부 생성을 핵심 요약.

다음 시간에는 Worktree 관리 방법, 즉 생성된 목록 확인, 삭제, 정리 방법에 대해 다룰 것임을 예고.

워크트리 관리의 중요성 및 개념

워크트리 생성만으로는 하드 드라이브와 Git 저장소가 엉망이 될 수 있어 관리가 필요함을 강조.

메인 저장소의 `.git` 폴더와 워크트리의 `.git` 파일 간의 연결 구조를 설명.

`git worktree list` 명령어로 현재 연결된 워크트리 목록을 확인하는 방법을 설명.

`git worktree remove` 명령어로 워크트리를 안전하게 삭제하는 방법을 설명하며, `rm` 명령어를 사용하지 말 것을 권고.

`remove` 명령어가 저장되지 않은 변경사항을 보호하는 안전 장치를 제공함을 설명.

유령 워크트리 정리 및 워크트리 보호

`rm` 명령어로 폴더를 삭제했을 때 발생하는 '유령 워크트리' 현상을 설명.

`git worktree prune` 명령어로 유효하지 않은 유령 워크트리 기록을 정리하는 방법을 소개.

`git worktree lock` 명령어를 사용하여 불안정한 저장소에 있는 워크트리를 `prune`으로부터 보호하는 기능을 설명.

워크트리 삭제와 브랜치 삭제의 차이

`git worktree remove`는 물리적인 작업 공간을 삭제하는 것이고, `git branch -D`는 브랜치 포인터를 삭제하는 것임을 구분하여 설명.

실수로 삭제된 워크트리 복구 방법

네 가지 상황에 따른 워크트리 복구 방법을 설명.

상황 1: `rm` 후 복구할 것이 없는 경우, `prune`으로 정리 후 `add`로 재생성하는 방법.

상황 2: 폴더 삭제 후 스테이징된 변경 사항이 있는 경우, `.git` 파일을 수동으로 생성하여 복구하는 방법.

상황 3: 워크트리와 연결된 브랜치까지 삭제된 경우, `git reflog`를 사용하여 커밋 해시를 찾고 브랜치를 재생성하는 방법.

상황 4: 워크트리 폴더를 이동한 경우, `git worktree repair` 명령어를 사용하여 복구하는 방법.

핵심 명령어 요약 및 다음 내용 예고

`list`, `remove`, `prune`, `lock`, `repair` 다섯 가지 핵심 명령어를 요약.

다음 영상에서 베어 저장소 설정법 등 전문가들이 사용하는 고급 기술을 다룰 것임을 예고.

Git Worktree 고급 활용: Bare Repository 전략

베어 레포지토리 전략은 Git 데이터베이스와 실제 작업 파일을 완전히 분리하여 깔끔한 프로젝트 구조를 제공.

`git clone --bare` 명령어로 순수한 Git 데이터베이스만 다운로드하고, `git worktree add`로 첫 작업 폴더를 연결하여 베어 레포지토리를 설정하는 과정을 설명.

Git 2.48 이상 버전에서 상대 경로 기능 지원으로 이식성이 보장됨을 언급.

PR 리뷰를 위한 일회용 환경 구축

기존 PR 리뷰 워크플로우의 고통을 지적하며, 일회용 리뷰 환경의 필요성을 강조.

`git fetch` 명령어로 특정 PR을 로컬 브랜치로 가져오고, `git worktree add`로 격리된 샌드박스 폴더를 생성하여 테스트하는 과정을 설명.

리뷰 완료 후 `git worktree remove`와 `git branch -D`로 샌드박스를 깔끔하게 정리하는 방법을 설명.

Bare Repository에서의 명령어 사용 및 주의사항

기존 Worktree 명령어들은 동일하게 적용되지만, 베어 레포지토리에서는 `git -C .bare` 플래그를 사용하여 명령을 실행해야 함을 설명.

베어 레포지토리 루트에서 `git pull`을 실행하면 안 되는 이유와 올바른 `git fetch` 및 `git pull` 사용법을 설명.

Worktree를 활용한 병렬 개발 시나리오

기능 개발, PR 리뷰, 긴급 버그 수정을 동시에 처리하는 시나리오에서 워크트리가 제공하는 병렬 개발의 이점을 설명.

레거시 버전과의 충돌 없이 Node.js 버전을 분리하여 작업하는 시나리오를 제시.

워크트리 사용 시 디스크 공간 및 `npm install`과 같은 의존성 설치 시간 비용이 발생함을 설명.

PNPM과 같은 최신 패키지 매니저 사용 및 깔끔한 정리 습관을 통해 이러한 비용을 줄일 수 있음을 제시.

Git Worktree 시리즈의 1편, 2편, 3편 내용을 요약하며 배어 레포지토리 워크플로우까지 다뤘음을 강조.

개인 프로젝트에 베어 레포지토리 구조 적용, 별도 워크트리 생성하여 PR 리뷰 또는 버그 수정 경험을 해볼 것을 도전 과제로 제시.

Git Worktree로 여러 피처 동시에 개발하기 | AI 코딩 시대의 필수 스킬

스크립트