메인 콘텐츠로 바로가기
CTRL K

개요

이 가이드에서는 Git Worktree를 사용하여 여러 브랜치를 동시에 작업하는 방법을 알아봅니다. Git Worktree를 활용하면 브랜치 전환 없이 핫픽스, 코드 리뷰, 기능 개발을 병렬로 처리할 수 있습니다. 특히 프론트엔드 개발 환경에서 node_modules 재설치나 빌드 캐시 초기화 없이 작업을 전환할 수 있어 개발 생산성이 크게 향상됩니다.

이 문서를 완료하면 다음을 할 수 있습니다:

  • 하나의 저장소에서 여러 브랜치를 동시에 체크아웃하여 작업
  • 작업 중인 코드를 그대로 두고 급한 버그 수정
  • 의존성 충돌 없이 서로 다른 환경에서 테스트 실행
  • IDE 인덱싱 대기 없이 브랜치 간 빠른 전환

대상 독자: 중급 이상의 프론트엔드 개발자 예상 소요 시간: 15분

배경: 왜 Git Worktree가 필요한가?

기존 방식의 문제점

프론트엔드 개발을 하다 보면 다음과 같은 상황을 자주 겪습니다:

시나리오 1: 급한 핫픽스 요청

# 새로운 기능 개발 중
$ git status
On branch feature/new-dashboard
Changes not staged for commit:
  modified:   src/components/Dashboard.tsx
  modified:   src/utils/api.ts
 
# 갑자기 프로덕션 버그 수정 요청이 들어옴
# 선택지:
# 1. git stash 사용 → stash가 쌓이면 관리가 어려움
# 2. 임시 커밋 → 커밋 히스토리가 지저분해짐
# 3. 다른 디렉토리에 clone → .git이 중복되고 디스크 공간 낭비

시나리오 2: 의존성 버전 충돌

# main 브랜치: React 18 사용
$ npm install
# node_modules 설치 완료
 
# feature 브랜치로 전환: React 17 사용
$ git checkout feature/legacy-support
$ npm install  # 다시 설치해야 함 (시간 소요)

시나리오 3: 코드 리뷰 중 작업 중단

# 코드 리뷰를 위해 동료의 브랜치 확인
$ git checkout feature/colleague-branch
# 작업 중이던 파일들을 stash하거나 커밋해야 함
# 리뷰 후 다시 원래 브랜치로 돌아와서 stash pop

Git Worktree의 해결책

Git Worktree는 하나의 Git 저장소에서 여러 개의 작업 디렉토리(working tree)를 동시에 관리할 수 있게 해줍니다. 각 워크트리는 서로 다른 브랜치를 체크아웃하여 완전히 독립적으로 작업할 수 있습니다.

project/
├── .git/                    # 공유되는 Git 메타데이터
├── main/                    # 메인 워크트리 (main 브랜치)
│   ├── src/
│   └── node_modules/
├── feature-dashboard/       # 기능 개발용 워크트리
│   ├── src/
│   └── node_modules/        # 독립적인 의존성
└── hotfix-login/           # 핫픽스용 워크트리
    ├── src/
    └── node_modules/        # 또 다른 독립적인 의존성

Git Worktree란?

핵심 개념

**워크트리(Working Tree)**는 Git 저장소에서 실제로 파일을 수정하는 작업 공간입니다. 일반적으로 하나의 저장소는 하나의 워크트리만 가지지만, Git Worktree를 사용하면 여러 개의 워크트리를 생성하여 각각 다른 브랜치를 동시에 작업할 수 있습니다.

동작 원리

메인 워크트리 (Main Worktree)
├── .git/                           # Git 메타데이터 저장소
│   ├── worktrees/                  # 추가 워크트리 정보
│   │   ├── hotfix/                 # hotfix 워크트리 메타데이터
│   │   │   ├── HEAD                # 현재 커밋
│   │   │   ├── index               # 스테이징 영역
│   │   │   └── gitdir              # 워크트리 경로
│   │   └── feature/
│   ├── refs/                       # 브랜치, 태그
│   └── objects/                    # 커밋 객체 (공유됨!)

핵심 포인트:

  1. 메타데이터 공유: 모든 워크트리가 .git 디렉토리를 공유하므로 커밋, 브랜치 정보가 동기화됩니다
  2. 독립적인 작업 공간: 각 워크트리는 별도의 HEAD, index를 가지므로 서로 영향을 주지 않습니다
  3. 브랜치 잠금: 한 워크트리에서 체크아웃한 브랜치는 다른 워크트리에서 체크아웃할 수 없습니다

일반 Clone vs Worktree 비교

특징여러 번 CloneGit Worktree
디스크 사용량.git이 중복 (매우 큼).git을 공유 (효율적)
커밋 동기화git fetch/pull 필요자동 동기화
브랜치 충돌 방지없음 (실수 가능)자동으로 방지
설정 파일각각 관리 필요자동 공유

핵심 명령어

1. 워크트리 생성하기

기본 사용법

새로운 브랜치를 생성하면서 워크트리를 만듭니다:

git worktree add <경로> [브랜치명]

예시 1: 자동 브랜치 생성

# ../hotfix-login 경로에 hotfix-login 브랜치를 생성
$ git worktree add ../hotfix-login
 
# 출력:
# Preparing worktree (new branch 'hotfix-login')
# HEAD is now at a1b2c3d feat: Add dashboard component

경로의 마지막 부분이 자동으로 브랜치 이름이 됩니다.

예시 2: 기존 브랜치 사용

# 이미 존재하는 feature/new-ui 브랜치를 체크아웃
$ git worktree add ../feature-ui feature/new-ui
 
# 출력:
# Preparing worktree (checking out 'feature/new-ui')
# HEAD is now at d4e5f6g feat: Initial UI setup

예시 3: 브랜치 이름 지정하기

# 경로와 브랜치 이름을 다르게 설정
$ git worktree add -b hotfix/user-auth ../auth-hotfix main
 
# 출력:
# Preparing worktree (new branch 'hotfix/user-auth')
# Branch 'hotfix/user-auth' set up to track remote branch 'main'
# HEAD is now at a1b2c3d Latest commit

-b 옵션으로 브랜치 이름을 명시적으로 지정할 수 있습니다.

프론트엔드 프로젝트에서의 실전 예시

# 프로젝트 루트에서 작업 중
$ pwd
/Users/dev/projects/my-app
 
# 1. 핫픽스용 워크트리 생성
$ git worktree add ../my-app-hotfix -b hotfix/login-error main
 
# 2. 워크트리로 이동
$ cd ../my-app-hotfix
 
# 3. 의존성 설치 (독립적인 node_modules)
$ npm install
 
# 4. 개발 서버 실행 (다른 포트 사용)
$ npm run dev -- --port 3001

이제 원래 작업(/Users/dev/projects/my-app)은 그대로 두고, 새 워크트리에서 핫픽스 작업을 할 수 있습니다!

2. 워크트리 목록 확인하기

git worktree list

출력 예시:

$ git worktree list
/Users/dev/projects/my-app          a1b2c3d [main]
/Users/dev/projects/my-app-hotfix   a1b2c3d [hotfix/login-error]
/Users/dev/projects/my-app-feature  d4e5f6g [feature/new-dashboard]

각 줄은 다음 정보를 포함합니다:

  • 워크트리의 절대 경로
  • 현재 커밋 SHA
  • 체크아웃된 브랜치

상세 정보 보기:

$ git worktree list --porcelain
worktree /Users/dev/projects/my-app
HEAD a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
branch refs/heads/main
 
worktree /Users/dev/projects/my-app-hotfix
HEAD a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
branch refs/heads/hotfix/login-error

3. 워크트리 삭제하기

작업이 완료된 워크트리는 삭제하여 정리합니다:

git worktree remove <경로>

예시:

# 핫픽스 작업 완료 후
$ git worktree remove ../my-app-hotfix
 
# 또는 워크트리 디렉토리 내부에서
$ cd ../my-app-hotfix
$ git worktree remove .

주의사항:

  • 워크트리를 삭제해도 브랜치는 삭제되지 않습니다
  • 커밋되지 않은 변경사항이 있으면 오류가 발생합니다

강제 삭제 (커밋되지 않은 변경사항 무시):

$ git worktree remove -f ../my-app-hotfix

4. 워크트리 정리하기

삭제된 워크트리의 메타데이터를 정리합니다:

git worktree prune

이 명령어는 다음과 같은 경우에 사용합니다:

  • 워크트리 디렉토리를 수동으로 삭제한 경우
  • .git/worktrees/ 디렉토리가 정리되지 않은 경우
# 워크트리 정리 전 확인
$ git worktree list
/Users/dev/projects/my-app          a1b2c3d [main]
/Users/dev/projects/my-app-hotfix   a1b2c3d [hotfix/login-error] prunable
 
# prunable 상태의 워크트리 정리
$ git worktree prune
 
# 정리 후 확인
$ git worktree list
/Users/dev/projects/my-app          a1b2c3d [main]

5. 워크트리 이동하기

워크트리의 위치를 변경해야 할 때 사용합니다:

git worktree move <현재경로> <새경로>

예시:

$ git worktree move ../my-app-hotfix ~/temporary/hotfix
 
$ git worktree list
/Users/dev/projects/my-app        a1b2c3d [main]
/Users/dev/temporary/hotfix       a1b2c3d [hotfix/login-error]

주의: 워크트리를 수동으로 이동하면 Git이 추적하지 못하므로 반드시 git worktree move를 사용하세요.

실전 사용 사례

사례 1: 핫픽스 긴급 처리

상황: 새로운 대시보드 기능을 개발 중인데 프로덕션에서 로그인 버그가 발견됨

# 현재 작업 상태 확인
$ pwd
/Users/dev/projects/my-app
 
$ git status
On branch feature/new-dashboard
Changes not staged for commit:
  modified:   src/components/Dashboard.tsx
  modified:   src/components/Chart.tsx
  modified:   package.json
 
# 1. 핫픽스용 워크트리 생성 (main 브랜치 기반)
$ git worktree add ../my-app-hotfix -b hotfix/login-fix main
Preparing worktree (new branch 'hotfix/login-fix')
HEAD is now at a1b2c3d Latest stable commit
 
# 2. 핫픽스 워크트리로 이동
$ cd ../my-app-hotfix
 
# 3. 의존성 설치
$ npm install
 
# 4. 버그 수정
$ vim src/auth/login.ts
# 코드 수정...
 
# 5. 테스트 실행
$ npm test
✓ All tests passed
 
# 6. 커밋 및 푸시
$ git add .
$ git commit -m "fix: Resolve login authentication issue"
$ git push origin hotfix/login-fix
 
# 7. 원래 작업으로 복귀
$ cd ../my-app
$ git status
On branch feature/new-dashboard
Changes not staged for commit:
  modified:   src/components/Dashboard.tsx
  # 작업 내용이 그대로 유지됨!

결과: 작업 중이던 코드를 전혀 건드리지 않고 핫픽스를 완료했습니다.

사례 2: 코드 리뷰 전용 워크트리

상황: 팀원의 PR을 리뷰하면서 동시에 자신의 작업도 진행

# 1. 코드 리뷰 전용 워크트리 생성
$ git worktree add ../my-app-review
 
# 2. 리뷰용 워크트리로 이동
$ cd ../my-app-review
 
# 3. 리뷰할 브랜치로 전환
$ git checkout feature/pr-123
$ npm install
$ npm run dev
 
# VSCode에서 리뷰 진행...
# PR에 코멘트 작성, 로컬 테스트 실행
 
# 4. 다른 PR 리뷰 (같은 워크트리 재사용)
$ git checkout feature/pr-456
$ npm install
 
# 5. 리뷰 완료 후 원래 작업으로 복귀
$ cd ../my-app
# feature/new-dashboard 브랜치에서 계속 작업

팁: 리뷰 전용 워크트리를 하나 만들어두고 여러 PR을 순차적으로 리뷰할 수 있습니다.

사례 3: 의존성 버전이 다른 환경 테스트

상황: Next.js 13에서 14로 마이그레이션 중, 두 버전을 동시에 테스트

# 현재 작업: Next.js 13 (main 브랜치)
$ pwd
/Users/dev/projects/my-app
$ cat package.json | grep next
  "next": "13.5.0"
 
# 1. Next.js 14 마이그레이션 브랜치용 워크트리 생성
$ git worktree add ../my-app-next14 feature/upgrade-next14
 
# 2. 새 워크트리로 이동
$ cd ../my-app-next14
 
# 3. Next.js 14 설치
$ npm install
# package.json에서 "next": "14.0.0"
 
# 4. 개발 서버 실행 (다른 포트)
$ npm run dev -- --port 3001
 
# 터미널 분할하여 원래 워크트리도 실행
# Terminal 1: Next.js 13 (포트 3000)
# Terminal 2: Next.js 14 (포트 3001)

장점:

  • 두 버전을 실시간으로 비교 테스트
  • node_modules 충돌 없음
  • 브라우저에서 두 버전을 동시에 확인 가능

사례 4: 디렉토리 구조 체계화

추천 디렉토리 구조:

projects/
└── my-app/
    ├── .git/
    ├── main/                    # 메인 브랜치 (안정 버전)
    │   ├── src/
    │   └── node_modules/
    └── worktrees/
        ├── feature/
        │   ├── dashboard/       # feature/dashboard 브랜치
        │   └── auth/            # feature/auth 브랜치
        ├── hotfix/
        │   └── login/           # hotfix/login 브랜치
        └── review/
            └── pr-123/          # 코드 리뷰용

설정 스크립트:

#!/bin/bash
# create-worktree.sh
 
TYPE=$1  # feature, hotfix, review
NAME=$2
 
if [ -z "$TYPE" ] || [ -z "$NAME" ]; then
  echo "Usage: ./create-worktree.sh <type> <name>"
  echo "Example: ./create-worktree.sh feature dashboard"
  exit 1
fi
 
BRANCH="$TYPE/$NAME"
DIR="./worktrees/$TYPE/$NAME"
 
# 워크트리 생성
git worktree add -b "$BRANCH" "$DIR" main
 
echo "✅ Worktree created at: $DIR"
echo "📌 Branch: $BRANCH"
 
# 의존성 설치
cd "$DIR"
npm install
 
echo "✅ Dependencies installed"

사용 예시:

$ ./create-worktree.sh feature dashboard
✅ Worktree created at: ./worktrees/feature/dashboard
📌 Branch: feature/dashboard
✅ Dependencies installed
 
$ ./create-worktree.sh hotfix login
✅ Worktree created at: ./worktrees/hotfix/login
📌 Branch: hotfix/login
✅ Dependencies installed

장점과 한계

장점

✅ 개발 생산성 대폭 향상

IDE 인덱싱 시간 절약

  • VSCode나 WebStorm 같은 IDE는 브랜치 전환 시 프로젝트를 다시 인덱싱합니다
  • 워크트리를 사용하면 각 워크트리가 별도로 인덱싱되어 전환 시간이 없습니다
# 기존 방식: 브랜치 전환 시 IDE 인덱싱 대기
$ git checkout feature/other-branch
# VSCode가 다시 인덱싱 (10-30초 소요)
 
# 워크트리 방식: 이미 인덱싱된 워크트리로 이동
$ cd ../worktrees/feature/other-branch
# 즉시 작업 시작 가능!

✅ node_modules 재설치 불필요

시나리오: React 18과 React 17 브랜치를 번갈아 작업

# 기존 방식
$ git checkout react-18-branch
$ npm install  # 5-10분 소요
# 작업...
$ git checkout react-17-branch
$ npm install  # 또 5-10분 소요
 
# 워크트리 방식
$ cd ../react-18-worktree  # 이미 설치됨
$ cd ../react-17-worktree  # 이미 설치됨
# 재설치 불필요!

✅ Git Stash 사용 빈도 감소

# 기존 방식: stash 관리가 복잡
$ git stash save "WIP: dashboard layout"
$ git stash save "WIP: api integration"
$ git stash list
stash@{0}: WIP: api integration
stash@{1}: WIP: dashboard layout
stash@{2}: WIP: old work
# 어떤 stash를 pop해야 할지 헷갈림
 
# 워크트리 방식: 각 워크트리에 변경사항이 독립적으로 유지됨
# stash 불필요!

✅ 병렬 테스트 실행 가능

# Terminal 1: 메인 워크트리
$ npm test
# E2E 테스트 실행 중...
 
# Terminal 2: 핫픽스 워크트리
$ cd ../worktrees/hotfix/urgent
$ npm test
# 유닛 테스트 실행 중...
 
# 두 테스트가 서로 영향 없이 동시 실행됨

한계

⚠️ .gitignore된 파일은 복사되지 않음

새로운 워크트리는 .gitignore에 포함된 파일을 포함하지 않습니다:

# 메인 워크트리
$ ls -la
.git
.env              # 환경 변수 파일
node_modules/
build/
.DS_Store
 
# 새 워크트리 생성
$ git worktree add ../feature-worktree
 
# 새 워크트리에는 .env가 없음!
$ cd ../feature-worktree
$ ls -la
.git              # (워크트리 링크)
src/
package.json
# .env 없음, node_modules 없음, build 없음

해결 방법:

# .env 파일 복사
$ cp ../main/.env .
 
# 의존성 설치
$ npm install
 
# 빌드 실행
$ npm run build

⚠️ 초기 설정 시간 필요

워크트리를 생성할 때마다 초기 설정이 필요합니다:

# 1. 워크트리 생성
$ git worktree add ../feature-worktree
# 2. 의존성 설치
$ cd ../feature-worktree
$ npm install          # 5-10분
# 3. 환경 설정
$ cp ../.env.example .env
# 4. 빌드
$ npm run build        # 1-5분

팁: 초기 설정을 스크립트로 자동화하세요.

⚠️ 디스크 공간 사용 증가

각 워크트리는 독립적인 node_modules를 가집니다:

# 메인 워크트리
node_modules/    # 500MB
 
# 추가 워크트리 3개
worktrees/
  ├── feature/    # node_modules/ 500MB
  ├── hotfix/     # node_modules/ 500MB
  └── review/     # node_modules/ 500MB
# 총 2GB 사용

해결 방법:

  • 필요 없는 워크트리는 즉시 삭제
  • 심볼릭 링크로 node_modules 공유 (고급)

⚠️ 같은 브랜치를 여러 워크트리에서 체크아웃 불가

# 메인 워크트리에서 feature/dashboard 사용 중
$ git branch
* feature/dashboard
 
# 다른 워크트리에서 같은 브랜치 체크아웃 시도
$ cd ../worktrees/review
$ git checkout feature/dashboard
fatal: 'feature/dashboard' is already checked out at '/Users/dev/projects/my-app'

해결 방법:

  • 워크트리마다 다른 브랜치 사용
  • 또는 기존 워크트리에서 브랜치 전환

트레이드오프 요약

상황Git Worktree 사용기존 방식 사용
브랜치 간 잦은 전환✅ 추천 (빠른 전환)⚠️ IDE 인덱싱 대기
의존성 버전 다름✅ 추천 (독립 환경)❌ 재설치 필요
병렬 작업 필요✅ 필수❌ 불가능
간단한 브랜치 작업⚠️ 과할 수 있음✅ git checkout 사용
디스크 공간 부족❌ 비추천✅ 하나의 node_modules만
일시적인 변경⚠️ 과할 수 있음✅ git stash 사용

Best Practices

1. “One Purpose Per Tree” 원칙

워크트리를 작업(task)이 아닌 **목적(purpose)**에 따라 생성하세요.

❌ 나쁜 예: 작업마다 워크트리 생성

git worktree add ../feature-dashboard
git worktree add ../feature-navbar
git worktree add ../feature-footer
git worktree add ../feature-login
# 관리가 어려워짐

✅ 좋은 예: 목적별로 워크트리 재사용

# 기능 개발 전용
git worktree add ../worktrees/development
 
# 코드 리뷰 전용 (여러 PR 순차 리뷰)
git worktree add ../worktrees/review
 
# 핫픽스 전용
git worktree add ../worktrees/hotfix

사용 예시:

# development 워크트리에서 여러 기능 순차 작업
$ cd ../worktrees/development
$ git checkout feature/dashboard
# 작업...
$ git checkout feature/navbar
# 작업...

2. 메인 워크트리는 깨끗하게 유지

메인 워크트리(프로젝트 루트)는 안정적인 브랜치(main, develop)를 유지하세요.

# 메인 워크트리: main 브랜치 고정
$ pwd
/Users/dev/projects/my-app
$ git branch
* main
 
# 모든 개발 작업은 워크트리에서 진행
$ cd worktrees/development
$ git checkout -b feature/new-feature

장점:

  • Git 설정, 스크립트 작성 시 기준점 역할
  • CI/CD 배포 스크립트가 메인 워크트리 기준으로 작성 가능

3. 체계적인 디렉토리 구조 사용

추천 구조:

project/
├── .git/
├── main/                    # 메인 워크트리 (배포용)
└── worktrees/
    ├── feature/
    │   └── {feature-name}/
    ├── hotfix/
    │   └── {hotfix-name}/
    └── review/
        └── {pr-number}/

Bash 함수로 자동화:

# ~/.bashrc 또는 ~/.zshrc에 추가
wt-create() {
  local type=$1
  local name=$2
 
  if [ -z "$type" ] || [ -z "$name" ]; then
    echo "Usage: wt-create <type> <name>"
    echo "Types: feature, hotfix, review"
    return 1
  fi
 
  local branch="$type/$name"
  local dir="./worktrees/$type/$name"
 
  git worktree add -b "$branch" "$dir" main
  cd "$dir"
  npm install
}
 
# 사용
$ wt-create feature dashboard

4. 정기적으로 워크트리 정리

작업이 완료된 워크트리는 즉시 삭제하세요.

# 매일 작업 전 확인
$ git worktree list
 
# 불필요한 워크트리 삭제
$ git worktree remove ../worktrees/feature/old-feature
 
# 삭제된 워크트리 메타데이터 정리
$ git worktree prune

자동화 스크립트:

#!/bin/bash
# clean-worktrees.sh
 
echo "🔍 Checking worktrees..."
git worktree list
 
echo ""
echo "🧹 Pruning stale worktrees..."
git worktree prune -v
 
echo ""
echo "✅ Cleanup complete"

5. .gitignore에 워크트리 디렉토리 추가

워크트리를 프로젝트 내부에 생성하는 경우 .gitignore에 추가하세요:

# .gitignore
node_modules/
.env
build/
dist/
 
# 워크트리 디렉토리
/worktrees/

주의: 워크트리를 Git에 커밋하면 안 됩니다!

6. 셸 함수로 빠른 전환

워크트리 간 빠른 이동을 위한 셸 함수:

# ~/.bashrc 또는 ~/.zshrc
wt-list() {
  git worktree list
}
 
wt-go() {
  local name=$1
  local dir=$(git worktree list | grep "$name" | awk '{print $1}')
 
  if [ -z "$dir" ]; then
    echo "❌ Worktree '$name' not found"
    return 1
  fi
 
  cd "$dir"
}
 
wt-clean() {
  git worktree list | grep "prunable" | awk '{print $1}' | xargs -I {} git worktree remove {}
  git worktree prune
}
 
# 사용 예시
$ wt-list                    # 워크트리 목록
$ wt-go feature              # feature 워크트리로 이동
$ wt-clean                   # 정리

7. 테스트 포트 충돌 방지

병렬로 개발 서버를 실행할 때 포트 충돌을 방지하세요.

package.json 설정:

{
  "scripts": {
    "dev": "next dev",
    "dev:3001": "next dev --port 3001",
    "dev:3002": "next dev --port 3002",
    "dev:3003": "next dev --port 3003"
  }
}

사용:

# Terminal 1: 메인 워크트리
$ npm run dev          # 포트 3000
 
# Terminal 2: 워크트리 1
$ cd ../worktrees/feature/dashboard
$ npm run dev:3001     # 포트 3001
 
# Terminal 3: 워크트리 2
$ cd ../worktrees/hotfix/login
$ npm run dev:3002     # 포트 3002

8. CI/CD 고려사항

GitHub Actions 예시:

# .github/workflows/ci.yml
name: CI
 
on: [push, pull_request]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      # 워크트리 정리 (CI 환경에서 불필요)
      - name: Clean worktrees
        run: |
          git worktree list
          git worktree prune
 
      - name: Install dependencies
        run: npm install
 
      - name: Run tests
        run: npm test

다음 단계

심화 학습

고급 워크트리 사용법:

  • git worktree lock: 워크트리를 이동식 저장장치에서 사용
  • git worktree repair: 손상된 워크트리 복구
  • Detached HEAD 워크트리로 실험적 변경

관련 Git 명령어:

  • git stash: 임시 변경사항 저장
  • git cherry-pick: 특정 커밋만 가져오기
  • git reflog: HEAD 이동 히스토리 확인

추천 도구

VSCode 확장:

  • Git Graph: 워크트리별 커밋 히스토리 시각화
  • GitLens: 각 워크트리의 Git 정보 표시

CLI 도구:

  • tig: Git 히스토리 터미널 뷰어
  • lazygit: 대화형 Git 인터페이스

참고 자료

공식 문서:

커뮤니티 리소스:

자주 묻는 질문 (FAQ)

Q: 워크트리를 생성할 때 의존성도 자동으로 설치할 수 있나요?

A: Git Worktree 자체는 의존성 설치를 지원하지 않지만, 셸 스크립트로 자동화할 수 있습니다:

#!/bin/bash
# smart-worktree.sh
 
BRANCH=$1
PATH=$2
 
if [ -z "$BRANCH" ] || [ -z "$PATH" ]; then
  echo "Usage: ./smart-worktree.sh <branch> <path>"
  exit 1
fi
 
# 1. 워크트리 생성
git worktree add -b "$BRANCH" "$PATH" main
 
# 2. 워크트리로 이동
cd "$PATH"
 
# 3. 의존성 설치
echo "📦 Installing dependencies..."
npm install
 
# 4. 환경 변수 복사
if [ -f "../.env" ]; then
  cp ../.env .env
  echo "✅ Environment variables copied"
fi
 
echo "✅ Worktree ready at: $PATH"

Q: 워크트리 간 커밋은 어떻게 공유되나요?

A: 모든 워크트리는 .git 디렉토리를 공유하므로 커밋은 자동으로 동기화됩니다:

# 워크트리 1에서 커밋
$ cd ../worktrees/feature/dashboard
$ git commit -m "feat: Add new dashboard"
 
# 워크트리 2에서 즉시 확인 가능
$ cd ../worktrees/hotfix/login
$ git log
commit a1b2c3d (feature/dashboard)
feat: Add new dashboard  # 방금 만든 커밋이 보임

Q: 워크트리를 삭제하면 브랜치도 삭제되나요?

A: 아니요, 워크트리 삭제는 브랜치에 영향을 주지 않습니다:

# 워크트리 삭제
$ git worktree remove ../worktrees/feature/dashboard
 
# 브랜치는 여전히 존재
$ git branch
  main
  feature/dashboard  # 여전히 존재
  hotfix/login
 
# 브랜치도 삭제하려면 별도로 실행
$ git branch -d feature/dashboard

Q: 워크트리에서 git push하면 어떻게 되나요?

A: 일반적인 git push와 동일하게 작동합니다:

# 워크트리에서 커밋 및 푸시
$ cd ../worktrees/feature/dashboard
$ git add .
$ git commit -m "feat: Complete dashboard"
$ git push origin feature/dashboard
 
# 원격 저장소에 푸시됨
# 다른 워크트리에서도 `git fetch` 후 사용 가능

Q: 워크트리를 다른 컴퓨터로 옮길 수 있나요?

A: 직접적으로는 불가능합니다. 워크트리는 메인 저장소와 경로로 연결되어 있기 때문입니다.

해결 방법:

  1. 워크트리의 브랜치를 푸시
  2. 다른 컴퓨터에서 해당 브랜치를 clone 또는 워크트리로 생성
# 컴퓨터 1
$ git push origin feature/dashboard
 
# 컴퓨터 2
$ git fetch
$ git worktree add ../feature-dashboard feature/dashboard

마치며

Git Worktree는 프론트엔드 개발 생산성을 크게 향상시킬 수 있는 강력한 도구입니다. 특히 다음과 같은 경우에 매우 유용합니다:

  • ✅ 여러 브랜치를 동시에 작업해야 하는 경우
  • ✅ 급한 핫픽스가 자주 발생하는 경우
  • ✅ 코드 리뷰를 많이 하는 경우
  • ✅ 의존성 버전이 다른 브랜치를 오가는 경우

처음에는 낯설 수 있지만, 몇 번 사용해보면 git stash 없이도 편리하게 작업할 수 있다는 것을 깨닫게 될 것입니다.

시작하는 방법:

  1. 간단한 프로젝트에서 워크트리 하나를 만들어보세요
  2. 핫픽스 상황이 생기면 워크트리로 처리해보세요
  3. 점차 워크트리 사용을 늘려가세요

Happy coding! 🚀

댓글

•developjik
All content is licensed under CC BY-NC-SA 4.0 unless otherwise noted.