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

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

작업하던 파일들은 여기저기 널려 있습니다. 지저분한 작업 내용을 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 코딩 시대의 필수 스킬

Scripts