-
1. 브랜치 전략을 세우는 이유
- 여러 개발자가 하나의 프로젝트 소스코드를 다루며 각종 부작용이 발생한다.
- 대표적으로 머지 충돌 → 코드 유실, 코드 변조가 일어난다.
- 협업을 원활하게 하기 위한 약속이 필요하다.
2. 대표적인 브랜치 전략 종류
- GIT FLOW (https://github.com/nvie/gitflow?tab=readme-ov-file)
- Vincent Driessen이 제안한 깃 관리 전략. main, develop, feature, release, hotfix와 같은 브랜치를 사용하여 프로젝트를 체계적으로 관리하는 방식
- 장점
- 체계적인 릴리즈 관리
- 개발과 유지보수가 독립적으로 진행관리 되어 유지보수성의 용이함
- 여러 브랜치로 진행사항을 추적, 검토하여 긴 개발주기에 유용함
- 단점
- 복잡한 브랜치 구조로 작은 프로젝트나 빠른 릴리즈가 필요한 프로젝트에는 오히려 비효율
- 지속적인 배포에 부적합
- PR의 호흡이 길어 리뷰가 너무 오래걸림 -> 단조로운 승인 리뷰가 되기 쉬움
- PR 생성한 당사자는 PR에 대해서 “나의 코드” 라는 생각이 심어짐
- GITHUB FLOW (https://docs.github.com/en/get-started/using-github/github-flow)
- 깃허브가 제안한 깃 관리 전략. main과 feature 브랜치를 사용하여 빠르게 배포하고, 필요할 때마다 기능을 추가하는 방식.
- 장점
- main과 feature 브랜치만으로 간단하게 관리할 수 있어 작은 프로젝트나 빠른 개발 주기를 소화하기에 적합
- 각 기능이 완성되면 main 브랜치로 병합 후 바로 배포할 수 있어 빠른 배포가 가능.
- 코드 리뷰 및 테스트 프로세스가 짧아짐
- 단점
- 복잡한 릴리스 관리가 필요한 대규모 프로젝트에 부적합
- 충분한 테스트 없이 빠르게 병합하고 배포할 수 있어 코드의 안정성이 떨어질 가능성
- 브랜치가 항상 최신 상태를 유지해야 하므로, 릴리스 버전을 따로 관리하기 어려워 롤백이 어려움
- Trunk Based Development (https://trunkbaseddevelopment.com/)
- 한개의 브랜치(trunk)를 두고, 긴 기능(feature) 브랜치를 따로 두지 않고, 작은 단위로 쪼갠 기능 작업 후 trunk에 바로 통합하는 방식
- 장점
- 큰 프로젝트에서도 팀이 빠르고 빈번한 통합 가능 -> 빠른 개발/배포 주기 가능
- 동적이고 생산적인 코드 리뷰
- 내 코드가 아니라 팀 코드라는 인식이 생김
- 단점
- 아래의 규칙이 업무에 선행되어야 한다.
- 1주일 간격으로 코드 리뷰 미팅
- 풍부한 커밋 메시지 (커밋 1개당 1개의 PR인 셈)
- 페어 프로그래밍 (2인 이상이 코드를 봐야함)
- Feature Flag 사용 필요 (아직 배포되면 안되는 기능 토글로 비활성화하는 방법 - 마틴 파울러가 소개)
- 통합이 빈번해 안정성이 떨어짐