Nested Feature Branch Workflow 전략으로 브랜치 관리

때때로 큰 규모의 프로젝트를 시작할 때, 어떻게 브랜치 전략을 세울지 고민이 될 때가 있습니다. 이에따라 피쳐 단위의 프로젝트에서 브랜치를 어떻게 관리하고 있는지에 대해 제 경험을 정리해 보았고, 이를 정리한 간단한 플로우 차트를 그려서 간단하게 파트 전체와 공유하고자 합니다.

위 사진에서 왼쪽과

저는 이에대한 솔루션으로 Nested Feature Branch Workflow 전략을 사용하고 있습니다. 이 방식은 하나의 큰 기능을 개발할 때, 여러 개의 하위 기능 브랜치를 생성해서 작업을 진행하는 방식입니다. 각 하위 피처 브랜치는 하나의 Root 브랜치에서 분기하며, 각각의 독립적인 작업을 진행합니다. 각 작업이 완료되면, 그것들을 Root 브랜치로 다시 merge하게 됩니다. 그리고 최종적으로 직접적으로 develop 브랜치에 병합되는 브랜치는 Root 브랜치 단 하나뿐입니다.

주요 브랜치는 크게 4가지로 분리됩니다 (Root / 레이아웃 / API 연동 / 비즈니스 로직) 이 네 가지 브랜치는 특정 조건에 따라 더 세부적으로 더 나뉘기도 합니다.

if… 공통 컴포넌트를 다루며, 같은 레포를 사용하고 있는 동료들에게 알려야 하는 경우 if… 특정 비즈니스 로직이 복잡하고 규모가 크며 상세한 리뷰가 필요한 경우 if… 작성한 코드에 대해 확신이 없고 동료들의 조언이 필요한 경우 해당 방식 도입 이후, 각 기능 또는 수정 사항을 독립된 브랜치에서 작업함으로써 변경 사항을 더 잘 파악할 수 있게 되었고, 코드 리뷰의 효율성을 높이는데도 큰 도움이 되었습니다.

그러나 이 방식에도 몇 가지 단점이 있습니다:

복잡성: Nested Feature Branch Workflow는 복잡한 구조를 가지고 있습니다. 여러 하위 브랜치를 동시에 관리해야 하며, 이는 브랜치 간의 의존성을 증가시키고 충돌 가능성을 높일 수 있습니다. 관리 오버헤드: 이 방법은 브랜치 관리에 상당한 노력을 필요로 합니다. 그리고 매번 디스크립션을 작성해야하는 번거로움도 있습니다. 병합 충돌: 하위 브랜치가 여러 개 있고 이들이 병합될 때, 병합 충돌이 발생할 수 있습니다. 이런 충돌을 해결하는 데는 시간과 노력이 필요합니다. 결론 모든 전략에는 장단점이 있듯이, Nested Feature Branch Workflow도 마찬가지입니다. 그러나 코드 리뷰의 생산성을 높인다는 장점이 아래의 세 단점을 상쇄한다고 생각합니다. 물론, 이 방식이 모든 크루 업무에 적합하다고 말할 수는 없지만, 협업을 많이 하는 채용 크루에서는 매우 유용하게 작용했습니다. 따라서, 큰 규모의 프로젝트를 진행한다면 이 방식을 활용해 볼 만한 가치가 있다고 생각합니다.