Git 브랜치 전략은 어떻게 선택하나요?

# 전략 없이 main에 직접 작업하는 경우

git checkout main
git pull origin main

# 기능 개발, 버그 수정, 실험을 모두 main에서 진행
git add .
git commit -m "기능 추가 및 버그 수정"
git push origin main

# 문제: 미완성 기능과 버그 수정이 섞여 롤백이 불가능합니다.
# 특정 기능만 되돌리려면 커밋 전체 히스토리를 뒤져야 합니다.

# 브랜치를 만들지만 네이밍 규칙이 없는 경우

git checkout -b fix           # 어떤 수정인지 알 수 없음
git checkout -b my-branch     # 작업 내용을 알 수 없음
git checkout -b test2         # 이전 test는 어디에?

# 브랜치가 쌓이면 어느 것이 활성 브랜치인지 파악이 안 됩니다.

# 1. main에서 기능 브랜치를 만듭니다.
#    네이밍 규칙: {타입}/{작업-내용}
git checkout main
git pull origin main
git checkout -b feat/add-login-page

# 2. 작업 후 커밋합니다.
git add .
git commit -m "feat: 로그인 페이지 UI 추가"

# 3. 원격에 push하고 Pull Request를 엽니다.
git push origin feat/add-login-page
# GitHub에서 PR 생성 → 코드 리뷰 → main에 머지

# 4. 머지 후 브랜치를 삭제합니다.
git branch -d feat/add-login-page
git push origin --delete feat/add-login-page

# 주요 브랜치 구조
# main      — 배포된 코드 (태그로 버전 관리)
# develop   — 다음 릴리즈를 위한 통합 브랜치
# feature/* — 기능 개발 (develop에서 분기, develop으로 머지)
# release/* — 배포 준비 (develop에서 분기, main + develop으로 머지)
# hotfix/*  — 긴급 수정 (main에서 분기, main + develop으로 머지)

# 기능 개발 시작
git checkout develop
git checkout -b feature/user-auth

# 기능 완료 후 develop으로 머지
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# 릴리즈 준비
git checkout -b release/1.2.0
# 버전 번호 업데이트, QA 후
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"

feat/로그인-기능-추가         # 새 기능
fix/헤더-레이아웃-버그        # 버그 수정
chore/의존성-업데이트         # 설정, 패키지 관리
docs/리드미-업데이트          # 문서
refactor/유저-컴포넌트-분리   # 리팩토링
hotfix/결제-오류-긴급수정     # 핫픽스