Git rebase와 worktree

히스토리 재작성과 멀티 브랜치 작업

git rebase는 내 커밋을 main 끝에 다시 붙여서 히스토리를 일직선으로 만든다. git worktree는 같은 repo를 여러 폴더에서 동시에 체크아웃해서 브랜치 전환 없이 작업한다.

Git
gitrebaseworktree

개념

git rebase와 git worktree는 서로 다른 문제를 푸는 기능이지만, 실무에서 같이 쓰기 좋다. rebase는 히스토리를 재작성해서 깔끔한 일직선 로그를 만들고, worktree는 같은 저장소를 여러 폴더에서 동시에 열 수 있게 해서 브랜치 전환 비용을 없앤다. 두 기능 모두 "기본 git 흐름의 불편함을 줄이는" 역할이다.

rebase

남의 작업(main)이 앞으로 갔을 때, 내 커밋들을 그 끝에 다시 붙이는 것.

전:
A - B - C          (main)
     \
      D - E        (내 브랜치)

후 (git rebase main):
A - B - C - D' - E'

D, E가 재작성되어 C 뒤에 붙는다. 커밋 해시가 바뀌는 게 포인트.

merge와 차이

결과 코드는 같고 히스토리 모양이 다르다.

  • merge — 가지 모양, merge commit 생김, 히스토리 보존
  • rebase — 일직선, 깔끔하지만 커밋 재작성

언제

  • PR 올리기 전에 main 최신화할 때 → rebase
  • PR 최종 합칠 때 → merge (또는 squash merge)

명령어

git rebase main

# 충돌 나면
git rebase --continue
git rebase --abort

# 커밋 정리 (최근 3개)
git rebase -i HEAD~3

주의

이미 push해서 팀이 같이 쓰는 브랜치에선 절대 rebase하지 말 것. 히스토리가 재작성되면 다른 사람 작업이 꼬인다. 혼자 쓰는 브랜치에서만.

worktree

같은 repo를 여러 폴더에서 동시에 열 수 있는 기능. .git은 하나인데 브랜치를 따로 체크아웃한다.

git worktree add ../repo-hotfix hotfix/login-bug
git worktree list
git worktree remove ../repo-hotfix

각 폴더는 독립적이다. ../repo-hotfix에서 커밋해도 원래 폴더의 feature 브랜치와는 관계없다.

언제 유용

  • 빌드가 무거워서 브랜치 전환 시 캐시 날아가는 게 아까울 때
  • IDE 인덱싱이 브랜치 전환마다 느릴 때
  • 두 브랜치를 나란히 보면서 비교할 때

대부분의 경우는 git stash + 브랜치 전환으로 충분하다. worktree는 "전환 비용이 정말 클 때"의 해결책.

sunshinemoon · 2026