[Git] PR Merge의 방법들과 각 방법의 특징

GitHub에서는 두 개의 브랜치를 머지(merge)하는 세 가지의 방법이 있다. 각 방법이 무엇인지, 그 특징은 무엇인지 알아보자.

 

 

1. Create a merge commit

• 두 브랜치의 변경 사항을 모두 유지하면서 병합
• 각 브랜치의 변경 사항이 과거의 커밋으로 보존되고, 새로운 커밋이 추가되어 최종 병합이 완료

장점

• 브랜치의 히스토리 모두 유지하면서 변경 사항을 병합할 수 있음
• 프로젝트의 진행 상황을 명황하게 이해하고 추적 가능
• 모든 커밋들의 커밋 아이디가 바뀌는 경우가 없기 때문에 squash와 rebase 방식에 비해서 비교적 사용이 쉬움

단점

• 커밋 히스토리가 복잡해질 수 있음
• 팀이 커질수록 이 복잡성을 빠르게 증가하게 됨

 

2. Squash and Merge

• 브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식
• 각각의 커밋에서 발생한 모든 변경 사항을 병합 후에 하나의 새로운 커밋을 생성

장점

• 커밋 히스토리를 간단하게 유지할 수 있음 (커밋 하나하나가 완성된 기능을 의미)

단점

• 작업의 상세한 이력을 잃게 됨
• 추후 문제 해결이 어려울 수 있음
• 새로운 커밋 아이디가 생성되기 때문에 여러명이서 해당 브랜치를 기반으로 작업을 수행하고 있었다면 병합이 이루어지는 경우 복작한 문제를 야기할 수 있음

(Git 자체가 아닌 GitHub에는 해당 커밋 기록들이 모두 남아있기 때문에 Pull Request를 검색해서 해당 작업의 커밋 히스토리를 확인할 수 있음)

 

3. Rebase and Merge

• 현재 브랜치를 target 브랜치에 재위치(rebase)시킨 후 병합하는 방식
• target 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨 놓는 것과 같음
• 커밋 히스토리는 선형적으로 유지

장점

• 깨끗하고 선형적인 커밋 히스토리
• 히스토리 파악 및 코드의 변화 이해가 쉬워짐

단점

• 관련된 커밋의 ID들이 모두 바뀌게 되어 혼란을 초래할 수 있음
• 여러 개발자가 동시에 작업을 수행한 경우에는 복잡한 충돌을 일으킬 수 있음
• 특정 기능이 어디서부터 어디까지의 커밋으로 구현되었는지 알기 어려워짐