[Git] Merge 종류 (Merge / Squash & Merge / Rebase & Merge)

✏️

이번 프로젝트를 진행하면서 깔끔한 Git history를 위해 브랜치 전략으로 rebase를 사용해보기로 했다.
이전까지는 순-정 merge만 사용했었기 때문에 프로젝트를 들어가기 전에 merge 종류에 대해서 학습하고자 한다.

가정

dev 브랜치에서 feature 브랜치를 파서 작업한다고 가정한다.

---

1️⃣ Merge

일단 그동안 사용해왔던 merge 는 커밋 이력이 모두 남는 병합 방법이다.

$ git checkout dev
$ git merge feature

상황에 따라 Fast Forward 방식과 Recursive 방식으로 나뉜다.

[1] Fast Forward

dev 에서 feature로 분기된 이후 dev 에 새로운 커밋이 하나도 올라 오지 않은 경우

• feature 의 커밋 이력을 그대로 dev 에 가져올 수 있다.
  마치 복사하는 느낌스

[2] Recursive

dev 에서 feature로 분기된 이후 dev 에 새로운 커밋(C, D)이 올라온 경우

• dev 와 feature 을 공통 부모로 한 새로운 merge 커밋을 생성된다.
• Fast Forward merge 가 가능한 상태에서도 git merge 명령에 --no-ff 옵션을 주면
  강제로 merge 커밋을 생성할 수도 있다.

---

2️⃣ Squash & Merge

$ git checkout dev
$ git merge --squash feature
$ git commit -m "커밋 메시지"

Squash 는 여러 개의 커밋들을 합치는 것이다.
feature의 커밋들(a,b,c)이 합쳐져서 base 브랜치에 하나의 커밋으로 추가된다.

• 🟢 장점 : 병합된 브랜치의 자세한 커밋 내역이 남지 않기 때문에 Git history 를 깔끔하게 관리 가능
• 🔴 단점 : 어떤 커밋들을 병합했는 지 알 수 없기 때문에 자세한 커밋 내역 확인이 어려움

---

3️⃣ Rebase & Merge

$ git checkout feature
$ git rebase dev
$ git checkout dev
$ git merge feature

드디어 주인공 두-둥
rebase 는 말 그대로 base 를 재설정하는 것이다.
rebase 를 하면 기존 분기점이었던 base(A)에서 가장 최신 커밋(C)으로 base 가 설정된다.

• 🟢 장점 : 일반 merge 보다 Git history 를 깔끔하게 관리 가능
• 🔴 단점 : Commit Hash 또한 변경되어 Force Push 를 해야할 경우도 있으니 주의 필요

---

➕Tip

PR 을 merge 할 때 3가지 종류 중에 선택해서 merge 할 수 있는데,
설정에서 원하는 merge 방식만 가능하도록 막아둘 수 있다!
프로젝트 컨벤션에 맞게 설정해놓고 쓰면 좋을 듯~

📎 참고

• Merging vs. rebasing
• Git의 다양한 브랜치 병합 방법 (Merge, Squash & Merge, Rebase & Merge)
• GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기