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

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-branching-strategies	Git Branching Strategies	10_Wiki/Topics	verified	self	브랜칭 전략 branching strategy git flow github flow trunk-based development feature branch gitlab flow	none	A	0.95	applied	git branching ci-cd trunk-based github-flow git-flow feature-flag atomic-commit		2026-05-10	pending	language framework Git / DevOps 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)

# 매 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)

# 매 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)

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

# 매 standard-version (auto semver + changelog)
npx standard-version

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

Branch protection (GitHub)

# 매 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)

# 매 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)

git checkout feature/long-running
git fetch origin
git rebase origin/main
# 매 conflict 의 매 small batch 의 resolve.

Hotfix (branch from main)

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)