기능 브랜치가 main보다 뒤처져 있고 새 작업이 필요합니다. Git merge vs rebase는 그것을 가져오는 두 가지 방법 중의 선택이며 둘 다 올바릅니다. 차이는 이후 히스토리가 어떻게 보이느냐입니다.

아주 작은 저장소를 만들어 두 명령을 모두 실행하고 실제 출력을 아래에 붙였습니다. 상상 대신 결과를 직접 비교해 보세요. Git이 처음이라면 초보자를 위한 Git 튜토리얼(영문)부터 시작하세요.

git merge와 git rebase가 하는 일

git merge는 두 브랜치의 끝을 가져와 합칩니다. 양쪽 모두 새 커밋이 있으면 Git은 부모가 둘인 머지 커밋을 만듭니다. 이미 존재하는 것은 아무것도 바뀌지 않습니다.

git rebase는 내 브랜치에만 있는 커밋을 따로 빼 두고, 브랜치를 상대 브랜치의 끝으로 옮긴 뒤, 내 커밋을 하나씩 다시 적용합니다. 다시 적용된 커밋은 변경 내용이 같아도 새 해시를 가진 새 커밋입니다.

git merge 실습

출발점은 이렇습니다. main에 커밋 A, feature에 커밋 두 개(F1, F2)가 있고, 이후 main에 커밋 하나(M1)가 더 추가되었습니다. 이제 main을 feature에 merge합니다.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

그래프는 실제 과정을 보여 줍니다. 두 작업 흐름이 합쳐졌습니다. 원래 커밋 F1과 F2는 해시를 유지합니다. 대가는 머지 커밋이 하나 늘어나는 것이며, 바쁜 프로젝트에서는 그래프가 거미줄처럼 됩니다.

git rebase 실습

출발점은 같지만 이번에는 feature를 main 위로 rebase합니다.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

히스토리는 M1 이후에 작업을 시작한 것처럼 한 줄의 직선입니다. 해시를 보세요. F1은 5a71e3c에서 bf9149e로, F2는 082cc6a에서 1ff474b로 바뀌었습니다. Git이 다시 쓴 것이고, 그래서 rebase는 주의가 필요합니다.

merge와 rebase 나란히 비교

rebase의 황금률

내 저장소 밖에 존재하는 커밋은 rebase하지 마세요. rebase 후에는 내 브랜치가 서버의 사본과 달라지므로 푸시에 강제 옵션이 필요합니다. 동료가 옛 커밋 위에 작업을 쌓았다면 그들의 히스토리가 내 것과 어긋나고, 이를 정리하는 일은 고통스럽습니다.

내 개인 기능 브랜치를 rebase하는 것은 괜찮습니다. main이나 다른 사람들이 쓰는 브랜치를 rebase하는 것은 안 됩니다.

안전한 팀 워크플로

이 절차는 누구도 놀라게 하지 않으면서 히스토리를 깔끔하게 유지합니다. 대부분의 팀이 CI 파이프라인 앞에서 쓰는 방식이기도 하며, GitHub Actions CI/CD 가이드(영문)의 파이프라인이 그 예입니다.

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease는 마지막 fetch 이후 누군가 서버 브랜치에 푸시했다면 덮어쓰기를 거부합니다. 일반 --force는 이를 조용히 없애 버립니다. 풀 리퀘스트가 승인되면 main에 merge하세요.

잘못된 rebase를 되돌리는 방법

rebase는 파괴적으로 보이지만 옛 커밋은 한동안 Git의 reflog에 남아 있으므로 되돌릴 수 있습니다.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

위험한 rebase 전에 git branch backup으로 백업 브랜치를 만들어 두면 복구는 명령 한 줄입니다. 컨테이너에서 데이터베이스나 도구를 함께 돌리나요? 초보자를 위한 Docker 튜토리얼(영문)을 확인해 보세요.

마무리

Merge는 사실을 보존하고, rebase는 그것을 깔끔하게 유지합니다. 내 브랜치를 최신으로 만들 때는 rebase를, 결과를 전달할 때는 merge를 쓰고, 다른 사람이 의존하는 히스토리는 절대 다시 쓰지 마세요.

자주 묻는 질문

더 배우기 (영문 글)