Git 브랜치 전략 비교: Git Flow

Git 브랜치 전략이란?

Git 브랜치 전략은 팀이 기능 개발, 버그 수정, 릴리스를 어떤 브랜치 구조로 관리할지 정하는 규칙입니다. 전략 없이 브랜치를 만들면 충돌이 잦아지고, 배포 시점이 불명확해지며, 핫픽스 반영이 누락되는 사고로 이어집니다.

이 글에서는 실무에서 가장 많이 쓰이는 4가지 브랜치 전략(Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development)의 구조, 장단점, 팀 규모별 선택 기준을 정리합니다.

4가지 브랜치 전략 한눈에 비교

Git Flow: 전통적 릴리스 관리

Vincent Driessen이 2010년에 제안한 모델로, 명확한 릴리스 주기가 있는 프로젝트에 적합합니다.

브랜치 구조

main          ← 운영 코드 (태그로 버전 관리)
develop       ← 다음 릴리스 통합 브랜치
feature/*     ← 기능 개발 (develop에서 분기, develop으로 머지)
release/*     ← 릴리스 준비 (develop에서 분기, main+develop으로 머지)
hotfix/*      ← 긴급 수정 (main에서 분기, main+develop으로 머지)

장점과 단점

GitHub Flow: 단순함의 힘

GitHub에서 권장하는 전략으로, 브랜치는 main과 feature 둘뿐입니다. PR(Pull Request)이 승인되면 main에 머지하고 즉시 배포합니다.

워크플로

# 1. feature 브랜치 생성
git checkout -b feature/user-profile main

# 2. 작업 후 커밋
git add .
git commit -m "feat: add user profile page"

# 3. 원격에 푸시하고 PR 생성
git push origin feature/user-profile

# 4. 코드 리뷰 → 승인 → main에 머지 → 자동 배포

이 전략이 동작하려면 main 브랜치가 항상 배포 가능한 상태여야 합니다. 이를 보장하는 것은 CI 파이프라인의 자동 테스트입니다.

GitHub Flow가 적합하지 않은 경우

• 스테이징 환경에서 별도 QA가 필요한 경우 (환경 브랜치가 없음)
• 여러 버전을 동시에 유지보수해야 하는 경우 (릴리스 브랜치가 없음)
• 배포 승인 프로세스가 복잡한 조직

GitLab Flow: 환경 기반 승격

GitHub Flow의 단순함에 환경(environment) 브랜치를 추가한 전략입니다. 코드가 main → staging → production 순서로 승격됩니다.

main          ← 개발 통합 (CI 통과 코드)
staging       ← QA/스테이징 환경 반영
production    ← 운영 환경 반영

각 환경 브랜치로의 머지가 해당 환경 배포를 트리거합니다. 이 구조는 “코드가 어느 환경에 배포되어 있는가”를 브랜치만 보고 파악할 수 있다는 장점이 있습니다.

Trunk-Based Development: 빠른 통합

Google, Meta 등 대형 테크 기업에서 사용하는 전략입니다. 모든 개발자가 main(trunk)에 직접 커밋하거나, 하루 이내에 머지되는 짧은 수명의 브랜치를 사용합니다.

핵심 규칙

1. feature 브랜치 수명은 최대 1~2일
2. 큰 기능은 Feature Flag로 코드에 숨긴 채 머지
3. main은 항상 릴리스 가능한 상태 유지
4. 자동화된 테스트 커버리지가 높아야 안전

Feature Flag 예시

// Feature Flag로 미완성 기능을 main에 안전하게 머지
if (featureFlags.isEnabled('new-dashboard')) {
  return renderNewDashboard();
}
return renderLegacyDashboard();

팀 상황별 선택 가이드

실전 체크리스트

1. 팀의 배포 주기(일/주/월)와 QA 프로세스를 먼저 파악한 뒤 전략을 선택
2. 브랜치 네이밍 규칙(feature/, fix/, hotfix/)을 문서화하고 리포지토리 설정으로 강제
3. main 브랜치에 직접 푸시를 금지하고 PR 필수 설정 적용
4. CI 파이프라인에서 PR 머지 전 자동 테스트·린트·빌드 검증 구성
5. 머지 전략(Squash Merge, Rebase, Merge Commit) 중 하나를 팀 표준으로 통일
6. 장기 브랜치(2주 이상 미머지)가 있으면 정기적으로 리베이스하거나 분할

관련 글

• GitHub Actions Self-Hosted Runner 실전 구축 가이드 — 브랜치 전략에 맞는 CI/CD 파이프라인을 Self-Hosted Runner로 구성하는 방법을 확인하세요.
• Nginx 리버스 프록시 실전 가이드 — 브랜치별 환경 배포(staging/production)에서 Nginx 리버스 프록시 설정을 함께 참고하세요.

Git 브랜치 전략 선택이나 현재 팀 워크플로 개선에 대해 궁금한 점이 있으시면 문의 페이지를 통해 연락해 주세요.

7) Git Flow vs GitHub Flow vs Trunk-Based: 언제 무엇을 쓸까

기준	Git Flow	GitHub Flow	Trunk-Based
팀 규모	10명+, 릴리즈 관리팀 있음	2~10명, 스타트업	5~50명, CI/CD 성숙
배포 주기	2~4주 (릴리즈 사이클)	수시 (PR 머지 = 배포)	하루 수 회 (CD)
브랜치 수명	길다 (feature 수 주)	짧다 (1~3일)	매우 짧다 (수 시간)
머지 충돌	많음	적음	최소
전제 조건	없음 (전통적)	코드 리뷰 문화	Feature Flag, 강력한 CI

8) 브랜치 전략 전환 시 실전 가이드

# Git Flow → GitHub Flow 전환 체크리스트
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 1. develop 브랜치를 main에 머지하고 삭제
git checkout main
git merge develop
git branch -d develop
git push origin --delete develop

# 2. 진행 중인 feature 브랜치를 main 기반으로 리베이스
git checkout feature/user-auth
git rebase main
git push --force-with-lease

# 3. 브랜치 보호 규칙 설정 (GitHub)
# Settings → Branches → Branch protection rules
# ☑ Require pull request reviews (1명 이상)
# ☑ Require status checks to pass (CI 통과 필수)
# ☑ Require branches to be up to date before merging

# 4. CI/CD 파이프라인 수정
# - main 머지 시 자동 배포 트리거 추가
# - release 브랜치 관련 워크플로우 제거

# 5. 팀 공지 및 문서 업데이트
# - CONTRIBUTING.md에 새 브랜치 규칙 명시
# - PR 템플릿 업데이트

9) 커밋 메시지 컨벤션

브랜치 전략과 함께 커밋 메시지 규칙도 정해야 히스토리 추적이 가능합니다.

# Conventional Commits 형식
<type>(<scope>): <subject>

# 타입 목록
feat:     새 기능
fix:      버그 수정
docs:     문서 변경
style:    포맷팅 (세미콜론, 들여쓰기 등)
refactor: 리팩토링 (기능 변경 없음)
test:     테스트 추가/수정
chore:    빌드/도구 설정 변경
ci:       CI/CD 파이프라인 변경

# 예시
feat(auth): 소셜 로그인 Google OAuth 추가
fix(order): 결제 금액 0원 주문 방지 검증 추가
docs(readme): 개발환경 설정 가이드 업데이트

10) 관련 글

• GitHub Actions CI/CD 가이드 — 브랜치 전략과 연계한 CI/CD 파이프라인 설계입니다.
• GitHub Actions Self-Hosted Runner — 사내 러너로 CI 속도를 높이는 방법입니다.
• ArgoCD GitOps 가이드 — Trunk-Based 전략과 GitOps를 결합한 배포 자동화입니다.