[Github] 브랜치 병합 전략(Branch Merge Strategy) 이해하기: Merge Commit, Squash, Rebase
adjh54
2025. 2. 13. 22:57
728x170
해당 글에서는 브랜치 병합 전략에 대해 이해를 돕기 위해 작성한 글입니다.
1) 병합(Merge)과 풀 리퀘스트(Pull Request)
1. 병합(Merge)
💡 병합(Merge)
- 한 브랜치의 변경 사항을 다른 브랜치로 통합하는 과정을 의미합니다. Git에서는 두 개의 브랜치를 하나로 합치는 작업을 수행할 때 이를 이용합니다. - 이러한 병합 과정을 통해서 프로젝트의 모든 구성원이 동일한 메인 코드베이스에서 작업할 수 있으며, 이는 프로젝트의 전반적인 품질 향상으로 이어집니다.
💡 병합(Merge) 과정
- 아래에서는 메인 코드베이스를 관리하는 Main 브랜치와 개별 기능을 개발하는 Feature 브랜치가 있습니다. - Feature 브랜치에서 개발된 기능이 완성되면 Main 브랜치로 통합됩니다. - 이렇게 여러 브랜치의 코드를 하나로 통합하는 과정을 병합(Merge)이라고 합니다.
- 코드 변경사항을 병합하기 전에 다른 개발자들과 변경 내용을 공유하고 검토하는 협업 기능을 의미합니다. 즉, 소스코드 병합 이전에 코드 품질을 보장하고 팀 협업을 원활하게 하는 중간 과정을 의미합니다. - 위에 과정과 같이 모두가 메인 브랜치로 병합이 이루어진다면, 검토가 없는 소스코드가 병합이 될 수 있기에 풀 리퀘스트와 같은 중간 과정을 통해 코드의 품질을 검증합니다.
💡 풀 리퀘스트(Pull Request, PR) 과정
1. 개발자는 각각 feature 브랜치에서 작업을 수행하고 완료합니다. 2. PR을 생성하여서 변경사항을 제안합니다. 3. 팀원들이 코드를 리뷰하고 피드백을 제공합니다. 4. 필요한 소스코드 수정 작업을 진행합니다. 5. 승인 후 main 브랜치로 병합을 수행합니다.
- 해당 과정은 spring-boot-keycloak이라는 feacture 브랜치에서 main으로 병합을 위해 PR을 생성하는 과정입니다.
2) 브랜치 병합 전략(Branch Merge Strategy)
💡 브랜치 병합 전략(Branch Merge Strategy)
- Github에서 브랜치들을 메인 브랜치로 병합할 때 사용할 수 있는 전략들을 의미합니다. 이러한 각각의 전략은 서로 다른 장단점을 가지고 있어 프로젝트의 특성과 팀의 워크플로우에 따라 적절한 전략을 선택해야 합니다. - 특히, 프로젝트의 소스코드 히스토리를 어떻게 관리할 것인지에 대한 팀의 합의가 중요합니다.
병합 전략
설명
Merge Commit (기본 병합)
모든 커밋 히스토리를 보존하면서 병합하는 방식
Squash and Merge
여러 커밋을 하나의 커밋으로 압축하여 병합하는 방식
Rebase and Merge
커밋들을 베이스 브랜치 위로 재배치하는 선형적 방식
1. 병합 전략 설정
💡 병합 전략 설정
- 기본적으로 merge commit 방식으로 설정이 되어있습니다. 추가적인 병합 방법 설정이 필요하면 아래의 과정을 통해서 설정이 가능합니다 - Github > Settings > General > Pull Requests 탭에서 이를 지정할 수 있습니다.
- 해당 방식은 feature 브랜치의 모든 커밋 히스토리를 보존하면서 main 브랜치로 병합하는 가장 기본적인 방식입니다. - 병합 시점에 새로운 merge commit이 생성되며, 이는 두 브랜치의 히스토리를 모두 포함합니다. - 브랜치의 전체 개발 과정과 히스토리를 추적하고 싶을 때 유용합니다.
구분
설명
장점
- 모든 커밋 히스토리가 그대로 보존됩니다.(main 브랜치, feature 브랜치 커밋 정보가 모두 남습니다) - 브랜치의 컨텍스트를 완벽하게 유지할 수 있습니다. - 병합 과정이 명확하게 표시됩니다.
단점
- 많은 브랜치를 병합할 경우 히스토리가 복잡해질 수 있습니다. - 불필요한 커밋 내역까지 모두 저장됩니다. - main 브랜치의 히스토리가 다소 지저분해질 수 있습니다.
1. 처리 과정
💡 처리 과정
- 아래의 이미지를 확인해 보면, master(main) 브랜치로 시작하였던 것들이 feature 브랜치로 분리되어서 최종적으로 Merge commit을 수행과정을 설명합니다. - 해당 과정에서, feature 브랜치로 분리가 되었던 브랜치들에 대해서는 커밋에 대한 히스토리를 보존하면서 master(main)브랜치로 병합이 되는 과정입니다.
2. 사용 예시
💡 사용 예시
- 아래의 과정에서는 feature 브랜치인 spring-boot-keycloak이라는 브랜치를 main 브랜치로 PR을 수행한 과정입니다. - 이 과정을 통해서 feature 브랜치와 main 브랜치는 병합이 되었음을 확인할 수 있습니다.
4) 브랜치 병합 전략(Branch Merge Strategy) : Squash and Merge
💡 브랜치 병합 전략(Branch Merge Strategy) : Squash and Merge
- 해당 방식은 feature 브랜치의 여러 개의 커밋을 하나의 커밋으로 압축(squash)하여 main 브랜치로 병합하는 방식입니다. 이는 병합이 되지 않는 것이 아니라, 여러 커밋이 하나의 커밋으로 압축되어 '추가'가 되는 방식입니다 - 커밋 히스토리를 간단하게 관리하고자 할 때 유용한 전략입니다.
구분
설명
장점
- main 브랜치의 히스토리가 깔끔하게 유지됩니다. - 불필요한 커밋 내역이 정리됩니다. - 기능 단위로 커밋이 관리되어 추적이 용이합니다.
단점
- feature 브랜치의 상세한 커밋 히스토리가 사라집니다. - 개별 작업의 세부적인 변경사항을 확인하기 어렵습니다. - 병합 후 원본 브랜치의 커밋 정보가 손실됩니다.
1. 처리 과정
💡 처리 과정
- 아래의 이미지를 확인해보면, 가장 아래의 라인은 master 브랜치를 의미하고 C2에서 분산된 C5, C6, C7은 feature 브랜치를 의미합니다. 이 과정을 통해서 최종적으로 featrue 브랜치가 master 브랜치로 병합이 되는 "Squash and Merger" 방식이 수행이 됩니다.
- 해당 과정을 다시 확인해보면, C1 -> C2까지 동일한 브랜치로 수행하다가 C3와 C5로 분리가 되었습니다. - C5, C6, C7은 feature 브랜치를 의미합니다. 이 브랜치는 C7에서 master 브랜치로 병합을 수행하였습니다. - 이때, Squash And Merge 방식을 수행하여서 "Single commit for C5, C6, C7"이라는 메시지만 남기고 master 브랜치에 작업한 featrue 브랜치 정보들이 압축(squash)되어서 master 브랜치로 병합(추가)되는 과정으로 처리가 되었습니다.
2. 사용예시
2.1. Feature 브랜치 작업 완료
💡 Feature 브랜치 작업 완료
- Feature 브랜치로 spring-boot-excel-poi, spring-boot-keycloak이라는 브랜치에서 작업을 하고 spring-boot-keycloak는 spring-boot-excel-poi로 임시 병합을 수행하였습니다. - 최종 featrue 브랜치는 "spring-boot-excel-poi"에 있습니다.
2.2. Github PR 수행
💡 Github PR 수행
- spring-boot-excel-poi 브랜치를 main 브랜치로 Squash and Merge 방식을 통해 PR을 수행합니다.
2.3. PR 수행 성공 확인
💡 PR 수행 성공 확인
- 아래의 과정을 보면 #13이라는 PR 병합이 수행됨을 확인할 수 있습니다. 그런데 사실상 spring-boot-excel-poi라는 브랜치와 main 브랜치는 병합이 되지 않은 상태입니다.
- 이는 즉, 여러개의 커밋을 하나의 커밋으로 압축(squash)되어서 추가가 되었습니다. - 이를 통해서, feature 브랜치는 일회성으로 사용되기에 main 브랜치의 히스토리가 깔끔하게 유지가 됩니다.
💡 PR 수행 완료 확인
💡 Squash And Merge를 통해서 병합이 완료되었습니다.
- 이전 Merge Commit(기본 병합)과 다르게 featrue 브랜치와 main 브랜치가 병합이 되지 않았습니다. - 그렇지만 main 브랜치 안에는 featrue 브랜치의 작업 내용이 포함되었습니다. - 즉, feature 브랜치에서 압축(squash)된 정보가 main 브랜치에 추가되어 병합이 되었습니다.
5) 브랜치 병합 전략(Branch Merge Strategy) : Rebase and Merge
💡 브랜치 병합 전략(Branch Merge Strategy) : Rebase and Merge
- 해당 방식은 feature 브랜치의 커밋들을 main 브랜치의 최신 커밋 뒤에 재배치(rebase)하는 방식입니다. - feature 브랜치의 커밋들이 main 브랜치의 커밋 뒤로 이동하면서 선형적인 히스토리가 만들어집니다. - 깔끔하고 선형적인 커밋 히스토리를 원할 때 유용한 전략입니다.
구분
설명
장점
- 선형적이고 깔끔한 커밋 히스토리를 만들 수 있습니다. - 각각의 커밋 내역이 모두 보존됩니다. - 브랜치의 시작점이 최신 상태로 업데이트됩니다.
단점
- 충돌이 발생할 가능성이 높습니다. - 커밋의 해시값이 변경되어 추적이 어려울 수 있습니다. - 팀원들과의 협업 시 혼란을 야기할 수 있습니다.
1. 처리 과정
💡 처리 과정
- 아래의 이미지를 확인해보면, 중앙에 master(main) 브랜치와 feature 브랜치가 있습니다. 이는 서로 병합이 되지 않은 상태인데, featrue 브랜치를 master 브랜치로 병합을 수행과정에서 설명을 합니다.
- 해당 과정에서, featrue 브랜치를 main 브랜치로 "Rebase and Merge"을 수행하면 master(main) 브랜치의 최신 커밋 뒤로 순차적으로 재배치가 됩니다. 최종적으로 선형적인 히스토리가 구성이 되는 방식입니다.
2. 사용 예시
2.1. Feature 브랜치 작업 완료
💡 Feature 브랜치 작업 완료
- Feature 브랜치로 spring-boot-excel-poi, spring-boot-keycloak이라는 브랜치에서 작업을 하였고, spring-boot-keycloak는 spring-boot-excel-poi로 임시 병합을 수행하였습니다. 최종적으로 main 브랜치에 병합을 대기 중입니다.
2.2. Github PR 수행
💡 Github PR 수행
- spring-boot-excel-keycloak 브랜치(feature)를 main 브랜치로 Rebase and Merge 방식을 통해 PR을 수행합니다.
2.3. PR 수행 성공 확인
💡 PR 수행 성공 확인
- 아래의 과정을 보면 #16이라는 PR 병합이 수행됨을 확인할 수 있습니다.
💡 결과 확인
- 그런데 사실상 spring-boot-keycloak이라는 브랜치와 main 브랜치는 병합이 되지 않은 상태입니다. 이는 즉, main 브랜치 뒤에 히스토리로 재배치(rebase)가 되어서 추가가 되었습니다. - PR 과정에서 올린 “merge test xxx”와 “merge 테스트”라는 커밋 메시지가 main 브랜치에 재배치가 되어 히스토리로 유지가 되는 방식입니다.
