Git branch merge 방법들 알아보기

목차

1. Git 브랜치 머지 전략

2. 전략1 : Merge Commit

3. 전략2 : Squash and Merge

4. 전략3 : Rebase and Merge

5. Rebase + Squash로 커밋 기록 깔끔하게 정리하기

---

1. Git 브랜치 머지 전략

Git에서 두 개의 브랜치를 하나로 합치는 작업을 merge라고 한다.

베이스 브랜치가 다같이 공유하는 메인 코드를 가지고, 개발 작업을 할 때는 베이스로부터 브랜치를 뽑아내서 진행한다.

 

브랜치들을 베이스 브랜치에 병합할 때의 전략이 몇가지 있다.

• Merge Commit
  모든 커밋 히스토리를 보존하며 병합
• Squash and Merge
  여러 커밋을 하나의 커밋으로 압축하여 병합
• Rebase and Merge
  커밋들을 베이스 브랜치 위로 재배치하여 선형으로 병합

Github에서 PR을 올린 후, 병합할 때 머지 방법을 지정할 수 있다.

내가 하는 플젝에서는 Rebase and merge 방법을 채택하여 하고 있다.

 

---

2. 전략1 : Merge Commit

가장 기본적인 방법이다.

• 두 브랜치의 모든 커밋 기록을 포함한다.
• 병합할 때 새로운 merge commit이 생성된다.
• 브랜치의 전체 개발 과정과 히스토리를 모두 추적하고 싶을 때 유용하다.

기본 머지는 또 두가지 방법으로 나눠진다.

1. Merge (Fast-Forward)
2. Merge (Recursive) ← 더 일반적임

1. Merge (Fast-Forward)

작업 브랜치에서 (변경사항이 없는) 베이스 브랜치로 그대로 싸악 옮겨 붙이는 방식이다.

 

이 방식으로 진행하려면 베이스 브랜치로부터 작업 브랜치를 내고, 이후에 베이스 브랜치의 변경사항이 없어야 한다.

사실 팀 프로젝트를 할 때 사용하는 것이 거의 불가능하다고 보면 된다.

 

아래 그림에서 점 하나 = 커밋 기록 하나이다.

 

2. Merge (Recursive)

이게 일반적인 머지 방식으로, 베이스에서 변경사항이 있어도 머지를 할 수 있다.

작업 브랜치에서 작업을 하다가 베이스 브랜치의 끝부분으로 merge commit을 생성하며 병합하기 때문이다.

 

모든 히스토리를 보존하기 때문에 베이스가 많이 뚱뚱해질 수도 있다.

https://leetrue.hashnode.dev/branch-merge-strategy

 

https://leetrue.hashnode.dev/branch-merge-strategy

내가 가진 merge commit이 없어서 누군가의 것을 예시로 가져와봤다.

 

파란색 : 베이스(main) 브랜치

나머지 : 작업 브랜치

 

작업 브랜치를 생성할 때 베이스 브랜치에서 나왔다가,

병합할 때 다시 들어가는데 그 때 가지는 것이 merge commit이다.

 

모든 커밋 기록들이 기록되면서도 히스토리가 좀 지저분해보일 수 있다.

 

 

 

 

 

merge 명령어는 아래와 같다. 

git checkout main
git merge feature/branch

---

3. 전략2 : Squash and Merge

작업 브랜치에서 생긴 여러 개의 커밋을 합쳐서 하나의 커밋을 베이스 브랜치에 추가한다.

merge commit과 다르게 히스토리가 뚱뚱해지지 않는다.

 

작업 브랜치에서 생성했던 커밋 기록들이 없어지고 squash merge를 진행할 때 입력하는 커밋메세지만 남게된다.
작업에 대한 히스토리를 따로 기록하고 싶다면 이 때 커밋 바디로 작성해야한다.

 

 

명령어는 아래와 같다.

git checkout main
git merge --squash feature/branch
git commit -m "커밋 메세지 입력"

 

---

4. 전략3 : Rebase and Merge

말 그대로 base를 재설정하는 머지라는 뜻이다.

베이스 브랜치에 변경사항이 생겨 새로운 커밋들이 추가되었을 경우,

병합할 때 작업 브랜치를 뽑은 위치가 아닌 최신 위치를 base로 하여 작업 커밋들을 살려 병합한다.(이 과정에서 커밋의 해시값이 바뀐다)

 

이건 내 git graph를 예시로 보자.

 

 

예시 사진을 보면 히스토리가 상당히 뚱띠한데,

이건 아직 pr만 올라가고 머지가 안된 브랜치들이다.

머지하면 선형으로 날씬해진다.

 

main 브랜치로부터 작업 브랜치를 뽑고,

머지하면 그대로 main 브랜치에서 커밋을 확인할 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

명령어는 아래와 같다.

git checkout feature/branch
git rebase main
# 충돌 해결
git add .
git rebase --continue

 

---

5. Rebase + Squash로 커밋 기록 깔끔하게 정리하기

rebase와 squash를 같이 사용해서 커밋 기록을 깔끔하게 정리할 수 있다.

작업 브랜치에서 squash로 커밋 기록을 정리하고

베이스 브랜치로 합칠 때 rebase를 하는 것이다.

목적	squash만	rebase + squash
병합 시 커밋 1개로 압축	✅ 가능 (merge --squash)	✅ 가능
불필요한 커밋 정리	❌ 못함 (커밋 내용 수정 불가)	✅ 가능
커밋 순서 변경/수정	❌ 못함	✅ 가능
커밋 메시지 병합/편집	✅ GitHub UI에서 자동	✅ CLI에서 세밀하게 조정 가능
작업 브랜치 자체를 깔끔하게 만들기	❌ 안 됨	✅ 됨

 

 

작업 중 베이스 브랜치 변경사항이 생겼을 경우,

# 작업 브랜치: feat/button
# 베이스 브랜치: main

git checkout feat/button
git fetch origin
git rebase origin/main
# .... 충돌 해결 ....

git add .
git rebase --continue

메인을 fetch, rebase 하면 된다.

 

 

이미 올린 PR에 최신 베이스 브랜치를 반영하려는 경우

git checkout feat/button
git fetch origin
git rebase -i origin/main

#vim에서 squash, pick 진행
pick a1b2c3 add button ui
squash a2b3c4 fix typo
reword a3c4b5 final

git push -f

이럴땐 커밋 해시가 변경되므로 꼭 push할 때 -f(--force)를 함께 해야한다.

 

 

 

참고

https://adjh54.tistory.com/665

[Github] 브랜치 병합 전략(Branch Merge Strategy) 이해하기: Merge Commit, Squash, Rebase

https://leetrue.hashnode.dev/branch-merge-strategy