Git merge & rebase 차이

브랜치 기반 협업을 위한 두 가지 선택지

Git은 브랜치 기반의 버전 관리 시스템입니다. 개발자들은 기능별 브랜치를 만들고, 작업을 마친 후 해당 브랜치를 main 또는 develop 브랜치에 반영하게 됩니다. 이때 브랜치를 합치는 방법은 크게 두 가지가 있습니다.

• git merge
• git rebase

이 둘은 기능적으로는 같은 목적(브랜치 병합)을 달성하지만, 내부 동작 방식과 커밋 히스토리 형태에서 큰 차이가 있습니다.

git merge: 분기점이 보존되는 안전한 병합

git merge는 브랜치 간 변경 사항을 통합하되, 분기점을 그대로 남깁니다. 예를 들어 feature 브랜치를 main에 병합한다면, main 브랜치에는 새로운 "병합 커밋"이 생성되며, 두 브랜치의 변경 내역을 모두 담습니다.

# main 브랜치로 이동
git checkout main

# feature 브랜치를 병합
git merge feature
  

 

이후 Git log는 다음과 같은 형태가 됩니다.

*   merge commit
|\
| * feature commit 2
| * feature commit 1
* | main commit
|/

 

merge의 경우, 브랜치 히스토리를 보존하므로 협업 시 누가 무엇을 했는지 명확히 알 수 있다는 장점이 있습니다. 또한, 충돌이 발생해도 Git이 명확하게 처리할 수 있습니다.

 

반면에, 커밋 로그가 복잡해질 수 있다는 단점이 있습니다 (특히 많은 브랜치를 병합하는 경우).

 

git rebase: 깔끔한 직선형 히스토리 만들기

git rebase는 말 그대로 "기반을 다시 설정"하는 동작입니다. 어떤 브랜치의 커밋을 다른 브랜치의 최신 커밋 뒤로 옮겨서, 마치 직선처럼 히스토리를 정리합니다.

# feature 브랜치에서 rebase 실행
git checkout feature
git rebase main
  

 

이후 Git log는 다음처럼 깔끔한 직선이 됩니다.

* feature commit 2 (rebased)
* feature commit 1 (rebased)
* main commit

 

그 후 병합 시에는 fast-forward가 가능하므로 병합 커밋 없이도 통합됩니다.

 

참고로, Fast-forward 병합은 현재 브랜치가 대상 브랜치의 조상(commit history)에 있을 경우에만 발생합니다. 이 경우 Git은 단순히 현재 브랜치를 대상 브랜치의 커밋 위치로 앞으로 이동시키기만 하면 되기 때문에, 별도의 병합 커밋이 생성되지 않고, 히스토리도 깔끔하게 유지됩니다.

git checkout main
git merge feature  # fast-forward

 

rebase의 경우, 커밋 로그가 깔끔해지고, Git bisect나 로그 분석이 쉬워집니다. 또한, 히스토리가 마치 순차적으로 작업한 것처럼 보이게 된다는 장점이 있습니다.

 

그러나, 공개된 브랜치에 rebase를 하면 안 됩니다! 커밋의 해시가 바뀌기 때문에 협업자와 충돌이 발생할 수 있습니다.

 

감사합니다!