Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

7.4 KiB

Raw Blame History

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

title

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)

7.4 KiB Raw Blame History