Git 브랜치 전략 : Git Flow, GitHub Flow, GitLab Flow, Trunk-Based
0. 개요
협업에서는 브랜치 전략이 작업 흐름을 표준화하고, 릴리스 위험을 낮추며, CI/CD 자동화를 단순화한다. 이 글은 대표적인 네 가지 전략을 비교하고, 팀 상황에 맞는 선택 기준과 실전 체크리스트를 제시한다.
1. Git Flow
Vincent Driessen이 제안한 전략으로, 복수 릴리스와 긴급 패치를 명확히 분리한다. 다음과 같은 브랜치를 사용한다.
- main: 제품의 최종 릴리스 버전을 관리한다. 항상 안정 상태를 유지한다. 태그를 이 브랜치에서 단다.
- develop: 다음 릴리스 후보 기능이 모이는 통합 브랜치다. 안정성은 main보다 낮다.
- feature/*: 기능 단위 작업 브랜치다. 완료 후 develop으로 병합한다. 예)
feature/login,feature/payment. - release/*: 릴리스 직전 안정화(버그 수정, 문서, 버전 올림)를 수행한다. 완료 시 main과 develop에 모두 병합한다.
- hotfix/*: 운영 중 발견된 치명적 이슈를 즉시 고친다. main에서 분기해 수정 후 main·develop 양쪽으로 반영한다.
1-1. 기본 흐름
1) feature/* 분기 → 구현/테스트 → PR → develop 병합
2) 릴리스시 release/* 분기 → 버그픽스/버전업 → main 병합+태그 → 변경분을 develop에도 병합
3) 운영 긴급 이슈 시 hotfix/* 분기(기준: main) → 수정 후 main 병합+태그, develop에도 병합
1-2. 브랜치/태그 규칙(권장)
- 네이밍:
feature/{scope}-{short-desc},release/{version},hotfix/{issue-id} - 태그:
vMAJOR.MINOR.PATCH(SemVer), 예:v1.4.2 - 머지: release/hotfix 완료 시 반드시 main과 develop에 모두 반영한다(이중 병합 누락 방지).
1-3. 장단점
- 장점
- 역할이 분리되어 대규모/다중 릴리스 환경에서 안전하게 운영한다.
- 긴급 픽스의 경로가 정형화되어 사고 복구가 빠르다.
- 단점
- 브랜치가 많아 커뮤니케이션/동기화 비용이 크다.
- 긴 수명의 develop이 생성되어 병합 충돌과 “릴리스 기차” 관리가 어려워질 수 있다.
- CD(상시 배포) 조직에서는 속도를 저해할 수 있다.
2. GitHub Flow
메인라인 중심의 심플한 전략이다. 상시 배포, 웹 서비스에 적합하다.
- main: 항상 배포 가능한 상태를 유지한다.
- 모든 작업은 짧은-lived 기능 브랜치에서 수행하고, 작은 PR로 main에 자주 병합한다.
- 병합 직후 자동 배포가 일반적이다(“merge → deploy”).
2-1. 핵심 규칙
- 작은 단위로 작업하고, 테스트를 통과한 변경만 main에 병합한다.
- 리뷰는 필수이며, PR에 CI를 연동해 품질을 보장한다.
2-2. 장단점
- 장점: 단순하고 빠르며, CD와 궁합이 가장 좋다. 롤백/릴리스가 간단하다.
- 단점: 릴리스 윈도우와 안정화 기간이 필요한 환경에는 정보 구조가 부족하다(예: release 브랜치가 없음).
3. GitLab Flow
환경(환경/브랜치) 중심 운영을 강조한다. 예: main → staging → production.
- main: 통합 브랜치
- 환경 브랜치:
staging,production등. main에서 staging으로 프로모션, staging에서 production으로 프로모션하는 식으로 “승급”한다. - 이슈 트래킹과 머지리퀘스트 흐름을 긴밀히 연결한다.
3-1. 장단점
- 장점: 환경별 안정화/검증 흔적이 브랜치로 남아 운영 가시성이 높다.
- 단점: 환경 수만큼 브랜치 동기화가 필요해 오버헤드가 생길 수 있다.
4. Trunk-Based Development(TBD)
trunk(=main) 하나를 중심으로 1~2일 내 병합을 원칙으로 한다. 대규모 조직은 Release Branch를 짧게만 운영한다.
- Feature Flags를 활용해 미완 기능도 main에 빠르게 통합한다.
- 롱런 브랜치를 지양하고, 병합 충돌을 초기에 해결한다.
4-1. 장단점
- 장점: 통합 비용 최소화, 배포 속도 극대화, 충돌을 “작을 때” 해결한다.
- 단점: 플래그 관리 복잡도와 운영 성숙도가 필요하다.
5. 어떤 전략을 선택할까? (의사결정 매트릭스)
| 상황/요구 | 추천 전략 | 이유 |
|---|---|---|
| 다중 릴리스, 온프레/규제 산업, 장기 안정화 필요 | Git Flow | 역할 분리, 핫픽스 루트 명확 |
| 상시 배포, 웹/SaaS, 작은 PR 중심 | GitHub Flow 또는 TBD | 단순/속도/자동배포 친화 |
| 환경별 검증/승급이 중요(staging→prod) | GitLab Flow | 환경 중심 운영 가시성 |
| 대규모 팀, 충돌 비용↓, feature flag 가능 | TBD | trunk 중심, 높은 배포 빈도 |
다이어그램 포인트: “전략 선택 트리” — 배포 빈도/규제/환경 수/팀 규모를 기준으로 분기.
6. 팀 공통 규칙 제안 (전략과 무관하게)
- 브랜치 네이밍
feature/{scope}-{short-desc},fix/{ticket-id}-{short},release/{version},hotfix/{ticket-id}-{short}
- 커밋 메시지
- Conventional Commits 권장:
feat:,fix:,docs:,refactor:,test:,chore: - 이슈 연동:
feat: add login (#123)
- Conventional Commits 권장:
- PR 규칙
- 최소 1~2명 리뷰 필수, CI 통과 필수, 변경 규모 상한(예: +400 lines) 권장
- CI/CD
- PR 시 테스트/정적분석, main 병합 시 배포(또는 staging 배포) 자동화
- 릴리스/태그
- SemVer:
MAJOR.MINOR.PATCH - 태그는 main 기준으로 생성하고 릴리스 노트를 자동 생성한다.
- SemVer:
- 보호 규칙
- main(및 필요 시 develop/staging): force-push 금지, 직접 커밋 금지, 리뷰/CI 필수
7. 실전 절차 예시
7-1. Git Flow식 릴리스
# feature 브랜치 생성
git checkout -b feature/auth
# 작업 후 PR → develop 병합
# 릴리스 준비
git checkout -b release/1.4.0 develop
# (버그 수정/문서/버전 업)
# 완료 후 main 병합 + 태그
git checkout main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
# develop에도 반영
git checkout develop
git merge --no-ff release/1.4.0
git push --follow-tags다이어그램 포인트: “release 병합 이중 반영” — main·develop 양방향 화살표 강조.
7-2. GitHub Flow식 배포
# 작은 기능 브랜치
git checkout -b feature/quick-fix
# 작업 후 PR → 리뷰 통과 → main 병합 → CI가 자동 배포7-3. Hotfix 공통 패턴(Git Flow 기준)
git checkout -b hotfix/1234-critical main
# 수정/테스트
git checkout main
git merge --no-ff hotfix/1234-critical
git tag -a v1.4.1 -m "Hotfix critical issue #1234"
git checkout develop
git merge --no-ff hotfix/1234-critical
git push --follow-tags8. 모놀리포/마이크로서비스 고려
- 모놀리포: 단일 릴리스 기차라면 GitHub Flow 또는 TBD가 단순하다. 다수 패키지의 동기 릴리스가 필요하면 Git Flow의 release 단계가 유용하다.
- 마이크로서비스: 서비스별 독립 릴리스가 일반적이므로 GitHub Flow/TBD가 적합하다. 공용 라이브러리는 별도 버저닝/태깅 규칙을 둔다.
9. 자주 겪는 문제와 예방책
- develop와 main 간 변경 누락 → release/hotfix 이중 병합 체크리스트 도입
- 장수 feature 브랜치 → PR 단위 축소, TBD/feature flag 도입 검토
- 태그·릴리스 노트 누락 → CI에서 태그/노트 자동화
- 환경별 설정 혼선 → GitLab Flow의 환경 브랜치나, main 태그 기반 프로모션 파이프라인 설계
10. 팀 템플릿(예시)
- 브랜치:
feature/{domain}-{summary},fix/{ticket}-{summary},release/{version},hotfix/{ticket}-{summary} - PR 제목:
[feat|fix|chore] scope: summary (#issue) - 머지 전략:
squash and merge권장(히스토리 단순화), 릴리스 브랜치는merge commit유지 가능 - 보호 규칙: 리뷰 1+, 상태 체크 필수, 서명된 커밋/태그 옵션 검토
11. 마무리
전략의 “정답”은 팀의 배포 빈도, 규제 수준, 환경 수, 운영 성숙도에 따라 달라진다. 기본은 단순성이고, 복잡성은 필요한 만큼만 추가한다. 팀이 작고 배포가 잦다면 GitHub Flow/TBD로 시작하고, 릴리스 안정화·승급이 중요해지면 Git Flow/GitLab Flow의 요소를 점진적으로 도입한다.
끄아악