Git 브랜치 전략 한눈에 정리👀

실무에서 자주 채택되는 Git Flow·GitHub Flow·GitLab Flow·Trunk‑Based Development 네 가지 전략 Git 브랜치 전략을 정리해봤습니다. 

 

1. Git Flow

개요

• 기능 개발, 릴리스 준비, 긴급 패치 단계를 브랜치로 명확히 구분합니다.
• main: 최종 릴리스(배포) 코드
• develop: 다음 릴리스를 준비하는 통합 브랜치
• feature/*: 단위 기능 개발
• release/*: 배포 전 안정화
• hotfix/*: 운영 긴급 수정

장점

• 각 단계가 분리되어 역할·책임이 명확합니다.
• 여러 버전을 병렬 유지하기 쉬워 온프레미스·패키지형 소프트웨어에 적합합니다.

단점

• 브랜치가 많아져 머지·리뷰 부담이 큽니다.
• 빠른 CI/CD(하루 여러 번 배포) 문화에는 과도하게 복잡할 수 있습니다.

---

2. GitHub Flow

개요

• main 브랜치만 운영 환경을 가리키며, 모든 작업은 **기능 브랜치(feature)**에서 시작합니다.
• Pull Request(PR)를 통해 코드 리뷰 & CI를 거친 뒤 main에 머지 → 자동 배포가 일반적입니다.

장점

• 과정이 단순해 작은 팀·웹 서비스에서 빠른 배포 주기를 달성할 수 있습니다.
• PR 기반 워크플로가 GitHub UI와 자연스럽게 맞물립니다.

단점

• 장기간 동시에 여러 릴리스를 유지해야 하는 환경에는 적합하지 않습니다.
• 긴급 패치와 배포 타이밍을 main 한 갈래에서 다뤄야 하므로 충돌 위험이 있습니다.

---

3. GitLab Flow

개요

• GitHub Flow의 단순함과 Git Flow의 버전 관리 개념을 유연하게 결합합니다.
• 보통 prod / pre / dev 같은 배포 단계별 기본 브랜치와, 기능·핫픽스 브랜치를 조합해 사용합니다.
• 이슈 트래킹, CI/CD 파이프라인을 GitLab 내부 기능으로 한 번에 관리하는 것이 특징입니다.

장점

• 팀 규모·배포 주기에 맞춰 브랜치 레이아웃을 자유롭게 설계할 수 있습니다.
• GitLab의 환경별 배포(Deploy Board), 파이프라인 시각화와 연동이 수월합니다.

단점

• 명확한 ‘정석’이 없기에 팀 내 합의·정책 문서화가 필요합니다.

---

4. Trunk‑Based Development (TBD)

개요

• 트렁크(보통 main) 한 갈래에 모든 개발자가 하루 안에 자주 머지합니다.
• 기능 스위치(Feature Toggle)나 분기된 빌드 파이프라인으로 미완성 기능을 숨기고, 작은 단위의 변경을 지속적으로 통합·배포합니다.

워크플로

 

• 작업 시작
  • 개발자는 짧은-lived 브랜치(short-lived branch) 또는 직접 트렁크에서 작업합니다.
  • 브랜치를 쓴다면 길어야 1~2일 유지 후 PR(Pull Request)로 머지합니다.
• 코드 작성 & Feature Toggle
  • 미완성 UI, API 호출 등은 **토글(예: LaunchDarkly, Firebase Remote Config, 자체 플래그)**로 감춥니다.
  • UI → API → DB 단계별로 스위치를 두어 점진적 활성화가 가능합니다.
• 로컬 단위 테스트
  • 최소 단위 테스트 통과 확인 후 PR을 올립니다.
• 자동 CI 파이프라인
  • PR 생성 시 빌드·단위 테스트·정적 분석이 자동 실행됩니다.
  • 리뷰어는 녹색 상태를 전제로 코드 리뷰를 진행합니다.
• 머지(Merge)
  • 승인이 완료되면 squash merge 또는 rebase merge 방식으로 트렁크에 합칩니다.
  • 머지 후 즉시 통합 테스트·배포 파이프라인이 실행됩니다.
• 배포(Continuous Delivery/Deployment)
  • 스테이징·프로덕션 환경으로 자동 배포하거나, 배포 승인 단계를 거친 뒤 릴리스합니다.
  • 새 기능 노출 여부는 토글로 제어하므로, “배포=릴리스”가 반드시 일치하지 않습니다.
• 토글 삭제(Dead Code Cleanup)
  • 기능이 완전히 안정화되면 토글과 관련된 죽은 코드를 제거해 코드베이스를 깔끔히 유지합니다.

 

장점

• 충돌을 초기에 해결해 병합 지옥을 예방합니다.
• Continuous Delivery/Deployment 문화에 최적화되어, 대규모 조직도 짧은 사이클 유지 가능.

단점

• 미완성 코드를 숨길 Feature Toggle 체계가 필수이며, 테스트 자동화 수준이 낮으면 품질 저하 위험이 큽니다.
• 코드 리뷰·품질 게이트 과정을 짧은 주기에 맞춰 고도화해야 합니다.

---

5. 브랜치 명명 규칙 팁

• feature/이슈번호‑설명: feature/1234-login-ui
• bugfix/설명: bugfix/crash-on-iOS17
• hotfix/버전‑설명: hotfix/1.3.2-payment-error
• release/버전: release/2.0.0

---

6. 커밋·머지 가이드 (공통 권장)

1. Commit 타입을 feat, fix, refactor, test, docs 등으로 구분해 Conventional Commits 체계를 유지합니다.
2. PR 템플릿에 “Test Checklist”, “Deployment Steps” 항목을 두어 항상 증적을 남깁니다.
3. main·prod는 Force‑push 금지, 필수 리뷰어 ≥ 1명 규칙을 리포지토리 레벨로 강제합니다.

---

7. 전략 선택 상세 체크리스트

질문	예/아니요	추천
릴리스를 하루에 여러 번 진행합니까?	예	GitHub Flow / TBD
온프레미스 고객에게 패치 브랜치를 오래 유지합니까?	예	Git Flow
QA → Stage → Prod 단계별 승인 절차가 존재합니까?	예	GitLab Flow
팀이 30인 이상이며 모놀리식 서비스입니까?	예	Git Flow → TBD 전환 단계적 검토
마이크로서비스 + 클라우드네이티브 구조입니까?	예	TBD + 서비스별 단독 레포