[Git] Merge 병합 방법 정리 (fast-forward, 3-way, squash)

실무를 진행하다보면, 한 브랜치에서 여러개 브랜치를 따서 작업을 진행하는 경우가 많다.

예를 들면,
dev 브랜치 - feature1 브랜치
                  - feature2 브랜치
                  - feature3 브랜치

이렇게 진행하다 Merge 할 때 꼭 문제가 발생한다.

이번에도 문제해결하면서 Git Merge에 대해 한번 싹 정리해두면 좋을 것 같아 쓰는 글.. :)

---

💡Git Merge 병합 방법

참고! 
이번 글에서 사용하는 대상 브랜치와 병합 브랜치라는 명칭이 좀 헷갈릴 수 있다.
- 대상 브랜치 : 부모 브랜치 (위에 든 예시로 보자면 dev)
- 병합 브랜치 : 자식 브랜치 (위에 든 예시로 보자면 feature1,2,3)

대상(부모)으로부터 병합(자식)이 만들어졌고,
다시 자식-> 부모로 병합한다고 보면 됨~

👉🏻 Merge 전략에 따른 방법 3가지

1. Fast-Forward 병합

• 대상 브랜치와 병합 브랜치의 commit history가 직선으로 이어질 수 있을 때 사용
  • 대상 브랜치의 현재 최신 상태에서 병합 브랜치가 분기된 경우
• 병합 커밋을 생성하지 않고, 바로 merge 가능

병합 전

병합 후

⚠️ Fast-Forward 방식은 병합 기록이 남지 않아 추적이 어려울 수 있다. 다인원 프로젝트의 경우 History 관리가 어려울 수 있어서, 개인적으로는 추천하지 않는다.

2. No-Fast-Forward 병합 (＝3-way Merge, 3방향 병합)

• 병합 커밋을 생성 👉🏻 어떤 브랜치에서 작업이 병합되었는지 추적 가능
  • 3방향 병합 : 3개의 참조점을 기준으로 비교해서 병합
    1. 공통 조상(아래 사진에선 'Commit B') : dev와 feature1의 공통적인 마지막 History
    2. dev 브랜치
    3. feature1 브랜치

병합 전

병합 후

✅ 병합(feature1) 브랜치가 삭제되더라도, 해당 커밋 기록들이 남아있어서 History 관리에 용이하다. 실무에서 내가 자주 사용하는 방식.

⚠️ 대상(dev) 브랜치의 히스토리가 복잡해질 수 있다

3. Squash 병합

• 병합 브랜치의 모든 커밋을 하나의 커밋으로 합쳐서 대상 브랜치에 반영
• 대상 브랜치에 히스토리가 간결화 됨

병합 전

병합 후

✅ 브랜치 내 불필요한 히스토리를 싹 없애서 깔끔하게 관리할 수 있다. 보통 한 사람이 한 브랜치에서 개발할 때, 자잘한 커밋이 많을 경우 squash를 사용 -> 깔끔하게 커밋 한개만 남기고 나머진 삭제하는 방식으로 사용.

⚠️ 한 브랜치에서 여러 기능을 개발해서 각 기능별로 커밋한 경우, 커밋 별 히스토리 추적이 어렵다.

---

👉🏻 작업 방식에 따른 방법 2가지

1. Rebase 후 병합

• 병합(feature1) 브랜치를 대상(dev)브랜치의 최신 상태로 정렬한 후 병합하는 방식
  
  • Fast-Forward 방식으로 Merge 하기 위해, Rebase를 사용하는 경우가 있음

병합 전

Rebase 후

병합 후

✅ 병합 기록이 따로 없어서 깔끔하게 히스토리 관리할 수 있음. 

⚠️ Rebase 하면서 충돌 발생할 수도 있고, 원격 브랜치에 강제 Push가 필요할 수 있음 => 협업 프로젝트의 경우 강제 push는 추가 충돌을 발생시킬 수 있기 때문에 되도록 권장하지 않음

 

2. Merge Commit을 생성하면서 병합하는 방법

위에 `No-Fast-Forward` 병합 방법이 이에 해당 됨.

 

---

💡결론

물론, 프로젝트마다 사람마다 Git Merge 운영 방식이 다를 것이다.

개인적인 경험으로는, 여러 사람이랑 협업해야 하는 실무 프로젝트에서는 `No-Fast-Forward 방식`을 사용하는 것이 가장 안정적이라고 생각한다.

그리고, 한 브랜치는 하나의 작업을 담당하며 Commit을 최대한 신중히 진행한다. (Commit 을 history로 관리할거라 마구잡이로 commit하지 않음)

하지만, 혹여나 한 작업에 Commit이 여러개 생성되어버린 경우,
Squash로 작업 내용을 합치고 squash 커밋 메시지에 "Squashed <브랜치명> branch : 작업 내용 요약" 를 적는 방식으로 관리한다.

즉, No-Fast-Forward를 기본으로 하되, 경우에 따라 Squash 방식을 혼용하는 것!