아키텍처
Git 브랜치 전략
두줄요약
Git Flow, GitHub Flow, GitLab Flow를 비교하며 실무 브랜치 전략의 핵심을 정리했습니다.브랜치 이름보다 역할과 배포 규칙의 일관성이 더 중요하다고 설명했습니다.
핵심 내용
- Git 브랜치 전략은 단순한 브랜치 분리가 아니라 협업 방식, QA, 배포, hotfix 대응까지 연결되는 팀 운영 규칙
- Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development의 특징과 적용 조건 정리
- 실무에서는 develop, stage, prod, release 같은 브랜치가 섞인 하이브리드 구조가 흔하며, 이름보다 역할·머지 방향·배포 기준이 중요
구조와 흐름
- 운영 브랜치, 개발 브랜치, 검증 브랜치, feature 브랜치, 배포 후보 브랜치로 역할 분리
- 개발 브랜치에서 먼저 통합 테스트를 하고, 배포 시점에는 운영 브랜치 기준으로 선택 feature만 배포 후보 브랜치에 모아 최종 검증
- 배포 후에는 운영 브랜치 기준으로 개발·검증 브랜치를 재동기화하고, hotfix는 운영 브랜치에서 분리해 처리
장단점
- 배포 범위를 명확히 제어하고 운영 배포 단위를 추적하기 쉬운 점이 장점
- 개발계 테스트와 운영 배포 조합이 달라질 수 있어 배포 후보 브랜치 기준의 최종 검증이 필요
- feature 간 의존성, conflict 집중, merge 방식 혼용, 공유 브랜치 동기화 누락에 주의 필요
적용해볼 점
- 각 브랜치의 역할, 보호 여부, 머지 방향, 배포 기준을 팀 규칙으로 명문화
- 배포 후보 브랜치 생성 시점과 포함 feature 선정 방식, hotfix 동기화 절차를 고정
- 장기 미노출 기능은 feature flag나 권한 제어와 함께 관리
