Merge 전략 3종 비교
PR 화면에서 초록색 Merge pull request 버튼을 누르면, 사실 GitHub는 이 버튼 하나에 3가지 병합 방식을 숨겨 두고 있습니다. 어떤 걸 고르든 최종 코드 결과물은 똑같지만, 커밋 히스토리 모양이 완전히 달라집니다.
Merge Commit
두 브랜치의 변경 사항을 모두 유지하면서, 병합을 나타내는 새 커밋 하나를 추가하는 방식입니다. 각 브랜치의 과거 커밋이 그대로 남습니다.
- 장점: 히스토리를 전부 보존. 커밋 ID가 안 바뀌어서 다루기 쉬움
- 단점: 브랜치가 많아질수록 히스토리가 지저분해짐
Squash and Merge
브랜치의 모든 커밋을 하나로 압축해서 병합합니다. 3~5개의 자잘한 커밋이 있었다면, 그게 전부 새 커밋 1개로 뭉쳐집니다.
- 장점: 커밋 하나 = PR 하나 = 완성된 기능 하나. 히스토리가 깔끔함
- 단점: 개별 작업 이력이 사라짐. 이미 같은 브랜치에서 여러 명이 작업 중이었다면 커밋 ID가 통째로 바뀌어 혼란이 생길 수 있음 (단, GitHub의 PR 자체 기록은 남아있어서 검색은 가능)
Rebase and Merge
현재 브랜치를 대상 브랜치 위로 **재배치(rebase)**한 뒤 병합합니다. 커밋들이 target 브랜치의 최신 커밋 위로 순서대로 옮겨 붙어서, 히스토리가 선형으로 유지됩니다.
- 장점: 깔끔하고 선형적인 히스토리
- 단점: 관련 커밋 ID가 전부 바뀜. 여러 명이 동시 작업 중이면 복잡한 충돌 유발 가능. 어떤 PR이 어디부터 어디까지였는지 구분이 어려워짐
비교 정리
| 방식 | 히스토리 형태 | 커밋 ID | 추천 상황 |
|---|---|---|---|
| Merge Commit | 브랜치 이력 그대로 + 병합 커밋 | 안 바뀜 | 처음 시작할 때, 규모가 작을 때 |
| Squash and Merge | PR 1개 = 커밋 1개 | 바뀜 | 히스토리를 깔끔히 유지하고 싶을 때 |
| Rebase and Merge | 완전 선형 | 바뀜 | 히스토리 순서가 중요할 때 |
처음에는 Merge Commit으로 시작해보고, 프로젝트가 커져서 관리가 힘들어지면 squash나 rebase로 정리하는 걸 추천합니다. 무엇보다 중요한 건 팀 내에서 방식을 통일하는 것입니다.
출처: Codyssey-B1/B2-2