[Git] - Git 브랜치 전략 실전 고찰: PR이 너무 커졌을 때의 분할 리뷰와 병합 전략
개발을 하다 보면 하나의 브랜치에서 너무 많은 작업을 하게 되어,
PR(Pull Request)이 커지고 리뷰가 어려워지는 상황을 겪게 됩니다.
이번 글에서는 제가 실제 겪었던 상황과 그에 대한 고민, 선택한 절충안, 그리고 사후 회고를 공유합니다.
문제 상황
초기 개발은 하나의 브랜치(A)에서 진행했지만, 너무 많은 커밋과 변경이 쌓이면서 PR이 커져 코드리뷰가 어려울 것이라는 판단이 들었습니다.
접근 방식
PR을 역할별로 나누고, 다음과 같은 흐름으로 정리했습니다.
A-1 (core 기능) A-2 (A-1에 의존) A-3 (A-1에 의존)
A-1,A-2,A-3브랜치는 모두main에서 파생 후,A브랜치의 커밋을 기능별로cherry-pick- 각 브랜치에 대해 개별 PR 생성 및 코드리뷰 진행
- 최종적으로는
A-1에A-2,A-3를 머지한 후,A-1을main에 머지
🚨 위기 상황: 커밋 해시 중복 문제
하지만 중요한 문제가 있었습니다.
A브랜치는 이미dev에 병합되어 있었고,
새로 만든A-1,A-2,A-3은main에서 따와cherry-pick한 상태였기 때문에
커밋 해시가 달라졌고, 결국dev에 병합 시 커밋이 중복되는 현상이 발생할 수 있다는 점을 발견했습니다.
이는 CI/CD에서 main -> dev 자동 머지 전략을 사용하는 경우, 커밋 기록이 지저분하게 남는 문제가 발생합니다.
최종 결정: 절충안
최종적으로는 다시 A 브랜치에서 PR을 생성하고,
PR 설명에 다음과 같이 역할별로 정리한 A-1, A-2, A-3의 리뷰 링크를 포함시키는 방식으로 절충하였습니다.
- 병합은 오직
A브랜치에서 진행 - 리뷰는
A-1,A-2,A-3에서 기능별로 분리하여 코드리뷰를 쉽게 - 리뷰어는 논리적 구분을 따라 기능별로 명확히 파악 가능
역할별 리뷰 구조:(PR내용에 포함)
1. A-2,A-3에 밑바탕이되는 코어부분 수정사항입니다. (A-1 into main PR링크 첨부)
2. A-2브랜치의 내용은 ~~입니다 (A-2 into A-1 PR링크 첨부)
3. A-3브랜치의 내용은 ~~입니다 (A-3 into A-1 PR링크 첨부)
정리
앞선 상황을 정리하면 아래와 같습니다.
- 개발 완료된 A 브랜치 존재
- 커밋 수가 많고 PR 리뷰 어려움 발생
- A에서 기능별 브랜치(A-1, A-2, A-3) 분기
- 각 브랜치에 기능별 커밋만 남기고 PR 생성
- 리뷰는 A-1 ~ A-3에서 개별로 진행
- 병합은 A 브랜치 하나로 일원화하여 main에 merge
- A-1 ~ A-3는 폐기
- 중복 커밋 없이 main/dev 이력 정리 가능
이 전략을 사전에 계획하고 개발을 진행했다면 훨씬 깔끔하게 마무리할 수 있었을 것입니다.
애초에 A브랜치를 생성 후 A-1브랜치를 따와 코어부분을 작업하고,
A-1브랜치가 완성되면 PR후 A에 병합
-> 이후 A-2브랜치가 완성되면 PR후 A에 병합
-> 이후 A-2브랜치가 완성되면 PR후 A에 병합하면 훨씬 깔끔하다고 생각합니다.
회고
이번 경험을 통해 알게 된 중요한 교훈 중 하나는, Git에는 하나의 정답만 있는 것이 아니다는 점입니다. (우리팀만 하더라도 이 상황에 대해 논의를 해본 결과 모두 다 다른 방향을 제시했거든요.)
브랜치 전략은 팀의 CI/CD 구조, 리뷰 문화, 그리고 배포 방식에 따라 달라질 수 있습니다.
중요한 건, 지속 가능한 Git 전략을 고민하고, 다음에 더 나은 선택을 할 수 있도록 기록을 남기는 일이라고 생각합니다.
이 기록도 누군가에게는 도움이 될 수도 있길 바라며(그럴 수 있겠죠?😅)
글을 마칩니다.
댓글남기기