Git 브랜치 전략: Git Flow부터 Trunk-Based까지

master (production)
  │
  ├── hotfix/payment-bug ────→ master + develop에 머지
  │
  ├── release/1.2.0 ─────────→ master + develop에 머지
  │
develop (통합 브랜치)
  │
  ├── feature/user-auth ──→ develop에 머지
  ├── feature/payment ────→ develop에 머지
  └── feature/notification → develop에 머지

# 1. 기능 개발 시작
git checkout develop
git checkout -b feature/user-auth
 
# 2. 기능 개발 완료 → develop에 머지
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth
 
# 3. 릴리스 준비
git checkout develop
git checkout -b release/1.2.0
 
# 4. 릴리스 완료 → master와 develop에 머지
git checkout master
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0
 
# 5. 핫픽스
git checkout master
git checkout -b hotfix/payment-bug
# 수정 후
git checkout master
git merge --no-ff hotfix/payment-bug
git tag -a v1.2.1 -m "Hotfix: payment bug"
git checkout develop
git merge --no-ff hotfix/payment-bug

main (trunk)
  │
  ├── short-lived branch (수 시간~2일)
  │     └──→ 빈번한 머지 (하루에 여러 번)
  │
  ├── short-lived branch
  │     └──→ 빈번한 머지
  │
  └── 항상 배포 가능한 상태 유지

// Feature Flag로 미완성 기능 제어
if (featureFlags.isEnabled("new-checkout-flow")) {
    return newCheckoutService.process(order);
} else {
    return legacyCheckoutService.process(order);
}

개발자 커밋 → main 머지 → CI 파이프라인
                            │
                      ┌─────┼─────┐
                      │     │     │
                   빌드   테스트  보안검사
                      │     │     │
                      └─────┼─────┘
                            │
                     자동 배포 (CD)
                            │
                    ┌───────┼───────┐
                    │       │       │
                Staging  Canary  Production

main ─── A ─── B ─── C ─── D ─── E ─── F
              \           /
               └── feat ──┘
                 (PR + Review)

main ──→ staging ──→ production

feature → main (개발)
            │
            ▼
         staging (테스트/QA)
            │
            ▼
         production (프로덕션)

main (항상 배포 가능)
  │
  ├── feature/xxx ──→ main에 머지
  │
  ├── release/2026.02 (릴리스 시점에 분기)
  │     └── cherry-pick (핫픽스만)
  │
  └── release/2026.03

monorepo/
├── services/
│   ├── auth-service/      ← 팀 A
│   ├── payment-service/   ← 팀 B
│   └── notification/      ← 팀 C
├── packages/
│   ├── shared-utils/      ← 공유 유틸리티
│   └── ui-components/     ← 공유 UI
└── tools/
    └── ci-scripts/        ← CI 도구

# Nx: 영향 받는 프로젝트만 테스트
npx nx affected --target=test
 
# Turborepo: 캐시된 결과 활용
turbo run build --filter=auth-service...

PR #1: 승인 → 머지 시도 → 성공
PR #2: 승인 → main이 변경됨 → 리베이스 필요 → 재테스트 → 머지 시도
PR #3: 승인 → 또 main이 변경됨 → 리베이스 필요 → 재테스트...

PR #1 ─┐
PR #2 ─┤──→ [Merge Queue] ──→ 자동 리베이스 → 테스트 → 머지
PR #3 ─┘         │
                 main은 항상 green 상태 유지

[기존: 하나의 큰 PR]
feature/big-change ──────────────────────→ main
(1000줄, 리뷰 어려움, 오래 걸림)
 
[스택드 PR: 여러 작은 PR 체인]
stack/part-1 (DB 스키마) ──→ main
    └── stack/part-2 (API) ──→ stack/part-1 위에 쌓임
         └── stack/part-3 (UI) ──→ stack/part-2 위에 쌓임

# Graphite 사용 예시
gt branch create part-1
# 변경 후
gt commit create -m "feat: add db schema"
 
gt branch create part-2  # part-1 위에 자동 스택
# 변경 후
gt commit create -m "feat: add API endpoints"
 
gt stack submit  # 전체 스택을 PR로 제출

# GitHub Actions에서 상태 검사 예시
name: CI
on:
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run lint

배포 빈도가 높은가? (하루 여러 번)
├── 예 → CI/CD 파이프라인이 견고한가?
│        ├── 예 → Trunk-Based Development
│        └── 아니오 → GitHub Flow
└── 아니오 → 여러 버전을 동시에 유지해야 하는가?
             ├── 예 → Git Flow 또는 Release Flow
             └── 아니오 → GitHub Flow