2nd/10_Wiki/Topics/AI_and_ML/Branching Strategies.md

---
id: wiki-2026-0508-branching-strategies
title: Git Branching Strategies
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [브랜칭 전략, branching strategy, git flow, github flow, trunk-based development, feature branch, gitlab flow]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
verification_status: applied
tags: [git, branching, ci-cd, trunk-based, github-flow, git-flow, feature-flag, atomic-commit]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: Git / DevOps
  framework: GitHub / GitLab / GitFlow
---

# Git Branching Strategies

## 📌 한 줄 통찰
> **"매 collaboration 의 traffic rule"**. 매 team size + CI maturity + release rhythm 의 따라 다름. 매 modern: **Trunk-Based + Feature Flag** 의 dominant. 매 long-lived branch 의 evil — 매 merge hell 의 source.

## 📖 핵심

### 매 4 main strategy

#### 1. Feature Branch Workflow (basic)
- `main` 의 stable.
- 매 feature 의 short-lived branch.
- 매 PR + review → squash merge.
- ✅ 매 entry-level. ✅ 매 small team.
- ❌ 매 long branch → 매 conflict.

#### 2. GitHub Flow
- `main` only + 매 feature branch.
- 매 deploy 의 매 merge 후.
- 매 simple + 매 CI 의 strict.
- ✅ 매 SaaS 의 continuous deploy.

#### 3. GitLab Flow
- `main` + `staging` + `production`.
- 매 environment 별 promotion.
- ✅ 매 staged release.

#### 4. Git Flow (Vincent Driessen 2010)
- `main`, `develop`, `feature/*`, `release/*`, `hotfix/*`.
- ✅ 매 versioned release.
- ❌ 매 heavy. 매 SaaS 의 outdated (Driessen 도 2020 의 retract).

#### 5. Trunk-Based Development (Google, Meta, Netflix)
- 매 모든 commit 의 `main` 의 직접 (또는 매 short-lived).
- 매 feature flag 의 incomplete 의 hide.
- 매 PR < 1 day.
- ✅ 매 fast feedback. ✅ 매 large team scale.
- ❌ 매 strong CI / feature flag 필수.

### 매 selection matrix
| 요인 | TBD | GitHub Flow | Feature Branch | Git Flow |
|---|---|---|---|---|
| Team size | Large | Small-Mid | Small | Mid-Large |
| CI maturity | High | Mid | Mid | Low |
| Release | Continuous | Continuous | Periodic | Versioned |
| Feature flag | Required | Optional | No | No |
| Conflict risk | Low | Mid | Mid-High | High |
| Onboarding | Hard | Easy | Easiest | Mid |

### 매 best practice (모든 strategy)

#### Branch naming
- `feature/PROJ-123-user-auth`
- `fix/PROJ-456-login-error`
- `chore/PROJ-789-update-deps`
- 매 kebab-case + 매 ticket ID.

#### Atomic commit
- 매 single logical change.
- 매 review 의 simple.
- 매 revert 의 easy.

#### Conventional Commits
- `feat:`, `fix:`, `chore:`, `refactor:`, `docs:`, `test:`, `perf:`.
- 매 changelog 의 auto.
- 매 semver 의 derive.

#### PR rule
- 매 직접 push X (`main` protect).
- 매 ≥1 review.
- 매 CI green.
- 매 merge 후 branch delete.
- 매 Squash / Rebase / Merge — 매 team policy.

#### Daily rebase / pull
- 매 long-lived branch 의 conflict 방지.

### 매 trunk-based 의 enabler

#### Feature flag
- 매 incomplete code 의 prod 의 deploy.
- 매 toggle ON/OFF.
- 매 Unleash, LaunchDarkly, GrowthBook.

#### Branch by abstraction
- 매 interface 의 swap.
- 매 main path 의 break X.

#### Strong CI
- 매 < 10 min build.
- 매 모든 PR 의 test.
- 매 protect rule.

#### Pair / mob programming
- 매 PR 의 substitute (real-time review).

### Stack (Graphite / Sapling)
- 매 1 feature = 매 N small PR (stack).
- 매 sequential merge.
- 매 large feature 의 manageable.
- 매 trunk-based 의 변형.

## 💻 패턴

### Feature Branch (typical)
```bash
# 매 start
git checkout main && git pull
git checkout -b feature/PROJ-123-user-auth

# 매 work
git add . && git commit -m "feat: add login form"
git push -u origin feature/PROJ-123-user-auth

# 매 PR (gh CLI)
gh pr create --title "feat: add user authentication" --body "..."

# 매 merge 후
git checkout main && git pull
git branch -d feature/PROJ-123-user-auth
```

### Trunk-Based (rapid)
```bash
# 매 small change directly
git checkout main && git pull
git checkout -b fix/typo
# 매 30 min change
git commit -am "fix: typo in README"
git push -u origin fix/typo
gh pr create --fill
# 매 squash merge in < 1 hour
```

### Feature flag (TBD enabler)
```ts
import { useFlag } from '@growthbook/sdk';

function Checkout() {
  const newCheckout = useFlag('new-checkout-flow');
  return newCheckout ? <NewCheckout /> : <OldCheckout />;
}

// 매 incomplete new path 의 prod 의 deploy. 매 flag ON 만 의 user 의 see.
```

### Conventional Commits + auto changelog
```bash
# 매 standard-version (auto semver + changelog)
npx standard-version

# 매 commitlint config
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
```

### Branch protection (GitHub)
```yaml
# 매 GitHub branch protection
protection:
  required_pull_request_reviews:
    required_approving_review_count: 1
  required_status_checks:
    strict: true
    contexts: [ci/build, ci/test, ci/lint]
  enforce_admins: true
  required_linear_history: true
  allow_force_pushes: false
```

### Stack-based PR (Graphite)
```bash
# 매 stack 의 create
gt create -m "feat: add API endpoint"
gt create -m "feat: add UI consumer"
gt create -m "feat: add tests"

# 매 base branch 의 update → 매 모든 stack 의 rebase
gt sync

# 매 stack 의 submit
gt submit
```

### Daily rebase (avoid conflict hell)
```bash
git checkout feature/long-running
git fetch origin
git rebase origin/main
# 매 conflict 의 매 small batch 의 resolve.
```

### Hotfix (branch from main)
```bash
git checkout main && git pull
git checkout -b hotfix/critical-security
# 매 fix
git commit -am "fix: patch SSRF vulnerability"
git push -u origin hotfix/critical-security
gh pr create --label urgent
# 매 fast-track merge → 매 immediate deploy
```

## 🤔 결정 기준
| 상황 | Strategy |
|---|---|
| Solo / hackathon | Direct to main |
| 2-5 dev | Feature Branch |
| SaaS continuous | GitHub Flow + feature flag |
| Mobile (versioned) | Git Flow or GitLab Flow |
| Large org | Trunk-Based + feature flag |
| Big feature | Stack-based PR |
| Open source | Feature Branch + maintainer review |

**기본값**: Trunk-Based with Feature Flag (modern). 매 Git Flow 의 avoid (대부분 의 case).

## 🔗 Graph
- 부모: [[Version-Control]] · [[DevOps]]
- 변형: [[Trunk-Based-Development]] · [[GitHub-Flow]] · [[Git-Flow]] · [[Feature-Branch]]
- 응용: [[Feature-Flag]] · [[Continuous-Deployment]] · [[Branch-by-Abstraction]] · [[Conventional-Commits]]
- Adjacent: [[CI CD]] · [[Code-Review]] · [[Semver]]

## 🤖 LLM 활용
**언제**: 매 team workflow 의 design. 매 Git strategy decision. 매 release process.
**언제 X**: 매 single-developer experiment. 매 throwaway prototype.

## ❌ 안티패턴
- **Long-lived branch**: 매 weeks → 매 merge hell.
- **Direct push to main**: 매 review 의 skip.
- **No CI before merge**: 매 broken main.
- **Git Flow 의 small team**: 매 over-engineering.
- **TBD without feature flag**: 매 broken prod.
- **No naming convention**: 매 chaos.
- **Squash 의 lose history**: 매 individual commit value.

## 🧪 검증 / 중복
- Verified (Atlassian docs, Trunk-Based Development website, Driessen 의 Git Flow retraction).
- 신뢰도 A.
- Related: [[Trunk-Based-Development]] · [[Feature-Flag]] · [[CI CD]] · [[Conventional-Commits]] · [[Quality_Code_Review_Modern]].

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — strategy matrix + best practice + 매 git workflow code (TBD, stack, hotfix) |