🔀

rebase vs merge, 언제 무엇을 쓰나

히스토리 보존과 선형화의 트레이드오프

둘 다 결과물(최종 파일)은 같을 수 있다. 차이는 히스토리의 모양이다.

브랜치 두 개를 합친 새 커밋(merge commit)을 만든다. 원래 커밋들은 그대로 남는다. 분기와 합류가 그래프에 그대로 보인다.

내 브랜치의 커밋들을 떼어내서, 다른 브랜치(보통 main)의 최신 커밋 위에 하나씩 다시 쌓는다. 원래 커밋은 버려지고 새 해시로 다시 만들어진다.

공유 브랜치는 rebase하지 않는다. 이미 남이 받아간 커밋을 rebase하면 해시가 바뀌므로 상대방의 히스토리와 충돌한다. 이게 'Golden Rule of Rebase'다.

개인 피처 브랜치는 rebase해서 main 위에 올려두는 게 깔끔하다. PR 올리기 전에 git rebase main으로 정리하면 리뷰어가 보는 diff가 최소화된다.

GitHub의 'Squash and merge' 버튼은 PR의 모든 커밋을 하나로 합쳐서 main에 넣는다. main 히스토리가 깔끔해지지만, 개별 커밋의 맥락은 사라진다. 트레이드오프다.

동작 흐름

merge: `git checkout main && git merge feature` → merge commit 생성

rebase: `git checkout feature && git rebase main` → feature 커밋을 main 위로 이동

interactive rebase: `git rebase -i HEAD~5` → 커밋 squash/edit/reorder

충돌 시 해결 후 `git rebase --continue` 또는 `git rebase --abort`

merge: 팀의 공식 브랜치 통합 (main ← develop, main ← release) rebase: PR 올리기 전 개인 브랜치 정리 squash: 작은 수정 커밋을 하나로 합쳐 main 히스토리 유지