Git에서 브랜치를 다른 브랜치와 합치는 방법에는 Merge와 Rebase 두 가지가 있다. 이 두 방법의 개념과 장단점을 비교해보고, 언제 어떤 방법을 선택해야 하는지 알아보자.
1. git merge vs git rebase 간단 비교
1) git merge
-
특징 :
기존의 브랜치는 변경되지 않으며, 새로운 merge commit이 추가된다. (브랜치 통합)
병합이 완료되면 두 브랜치는 같은 커밋을 가리키게 된다. -
장점 :
원래의 커밋 히스토리를 유지하면서 브랜치를 병합할 수 있다.
충돌이 발생해도 한 번에 해결할 수 있어 관리가 비교적 쉽다. (모든 짐을 한꺼번에 옮기는 느낌)
어떤 브랜치에서 merge가 발생했는지 명확하게 확인이 가능하다. -
단점 :
불필요한 merge commit이 추가되어 히스토리가 복잡해질 수 있다.
협업 과정에서 병합이 반복될 경우, 커밋 히스토리가 난잡해질 수 있다. -
예시:
현재 a 브랜치에 체크아웃 되어 있다고 가정하고
a 브랜치에 b 브랜치를 머지하는 과정
(a 브랜치에 새로운 merge 커밋이 생김)
git checkout a
git merge b
A---A1---A2---M (a)
\ /
B1-----B2 (b)2) git rebase
-
특징:
현재 브랜치를 다른 브랜치의 최신 커밋 이후로 이동(재배치)한다.
브랜치는 base 지점을 가지고 있어 base에서부터 코드를 수정한다. rebase는 이런 브랜치의 base를 재정의하여 commit history를 조작한다.
rebase가 이루어진 브랜치의 커밋을 다시 생성하기 때문에, 같은 커밋이라도 해시(hash) 값이 변경된다.
일반적으로 기능 브랜치를main으로 병합하기 전, 히스토리를 정리하는 용도로 사용된다. -
장점:
히스토리를 깔끔하게 유지할 수 있어, Git 로그가 직관적으로 정리된다.
불필요한 merge commit이 없어, 한 줄로 이어지는 간결한 Git 히스토리를 만들 수 있다. -
단점:
협업 중인 브랜치에서 rebase를 수행하면, 기존 커밋이 변경되므로 혼란을 초래할 수 있다.
충돌 발생 시, 각 커밋마다 충돌을 개별적으로 해결해야 한다. (짐을 하나씩 옮기는 느낌) -
예시:
# Before
main: A -- B -- C
\
feature: D -- E (HEAD)
# feature에서 `git rebase main` 후
main: A -- B -- C
\
feature: D' -- E' (HEAD) # D,E가 새 커밋으로 재작성
3. Merge vs Rebase 비교 이미지
- Merge는 기존 커밋 히스토리를 그대로 유지하며 새로운 merge commit이 추가된다.
- Rebase는 마치 처음부터 최신 브랜치에서 작업한 것처럼 커밋이 정리된다.
4. Merge와 Rebase를 언제 사용해야 할까?
-
Merge가 적절한 경우:
여러 개발자가 협업 중이며, 커밋 히스토리를 유지해야 할 때
Merge 히스토리를 확인하여 브랜치의 흐름을 명확하게 파악해야 할 때 -
Rebase가 적절한 경우 :
개인 브랜치에서 작업한 내용을 정리하여 히스토리를 깔끔하게 만들고 싶을 때
여러 개의 작은 커밋을 합쳐 하나의 논리적인 커밋으로 만들고 싶을 때
공유되지 않은 로컬 브랜치에서만 사용하는 것이 중요! -
𝐓𝐡𝐞 𝐆𝐨𝐥𝐝𝐞𝐧 𝐑𝐮𝐥𝐞 𝐨𝐟 𝐆𝐢𝐭 𝐑𝐞𝐛𝐚𝐬𝐞:
공유된(다른 개발자가 접근할 가능성이 있는) 브랜치에서는 절대 rebase를 사용하지 말 것.
Rebase는 커밋을 다시 생성하기 때문에, 원격 브랜치에서 rebase 후 push하게 되면 다른 개발자의 작업과 충돌할 위험이 크다.
5. 참고 자료
공식 문서 & 블로그
- Atlassian Git Tutorials: [Merging vs. Rebasing]
- Jeff Kreeftmeijer Blog: The magical and not-so-scary rebase
- 우아한테크 Youtube : [10분 테코톡] 글로의 git - merge and rebase
- [圖解] git merge 和 git rebase 差異
이미지 출처
