docs(10_Wiki): Topic_Business/General/Graphic/Programming을 Topics/ 하위로 이동
최상위 10_Wiki/Topic_*였던 4개 카테고리 폴더를 10_Wiki/Topics/Topic_* 로 재배치. 콘텐츠 변경 없음(순수 폴더 이동) — Topics/ 하위 나머지 폴더는 이미 지난 커밋에서 전부 정리된 상태(잔존 항목은 에이전트 운영 상태 및 사용자가 보존을 요청한 업데이트0615/무제 3.canvas 뿐).
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,264 @@
|
||||
---
|
||||
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) |
|
||||
Reference in New Issue
Block a user