Git 브랜치 전략 완벽 비교: Git Flow vs GitHub Flow vs Trunk-Based

main          ──●──────────────────────●── (배포 버전)
                │                      │
develop       ──●──●──●──●──●──●──●──●── (개발 통합)
                   │        │
feature/login ─────●──●──●──┘
                            │
feature/signup    ──────────●──●──●──┘

# 1. feature 브랜치 생성
git checkout develop
git checkout -b feature/user-login

# 2. 개발 및 커밋
git add .
git commit -m "feat: 로그인 기능 구현"

# 3. develop에 merge
git checkout develop
git merge feature/user-login
git branch -d feature/user-login

# 4. release 브랜치로 배포 준비
git checkout -b release/1.0.0
# 버그 수정, 버전 업데이트...

# 5. main과 develop에 merge
git checkout main
git merge release/1.0.0
git tag -a v1.0.0 -m "Version 1.0.0"
git checkout develop
git merge release/1.0.0

# 1. main에서 브랜치 생성
git checkout main
git checkout -b feature/add-search

# 2. 개발 및 커밋
git commit -m "feat: 검색 기능 추가"

# 3. Pull Request 생성 → 코드 리뷰 → main에 merge

# 4. 즉시 배포 (main == 프로덕션)

# 단명 브랜치 (1-2일 이내 merge)
git checkout -b feature/fix-button
git commit -m "fix: 버튼 스타일 수정"
git push
# PR → 즉시 merge

# 또는 직접 main에 push (소규모 팀)
git commit -m "chore: 패키지 업데이트"
git push origin main

if (featureFlags.isEnabled('new-dashboard')) {
  return <NewDashboard />
}
return <OldDashboard />

# Conventional Commits 형식
feat: 새로운 기능 추가
fix: 버그 수정
docs: 문서 수정
style: 코드 포맷팅
refactor: 리팩토링
test: 테스트 추가/수정
chore: 빌드 설정, 패키지 업데이트

# 예시
feat: 소셜 로그인 (Google OAuth) 구현
fix: 모바일에서 드롭다운 메뉴 닫히지 않는 문제 수정
docs: API 인증 방법 README에 추가