Git Flow

Git Flow

우리 팀은 GitHub Flow 기반 develop 브랜치를 추가한 커스텀 전략을 사용합니다.

브랜치 구조

main  ─────●──────────────●──────▶  (배포 / 프로덕션)
            ↑              ↑
develop ─●───●───●───●──●───┘        (개발 통합)
         ↑     ↑    ↑
feature ─┘     ─────┘               (기능 개발)

브랜치	역할	수명
main	배포용 브랜치. 항상 배포 가능한 상태를 유지	영구
develop	개발 통합 브랜치. 모든 기능이 여기에 모임	영구
{type}/기능명	개별 작업 브랜치 (아래 타입 표 참고)	작업 완료 후 삭제

작업 브랜치 타입

브랜치 prefix는 Commit Convention의 커밋 타입과 맞춰서 사용합니다.

Prefix	용도	예시
feature/	새로운 기능 개발	feature/login-api
fix/	개발 중 버그 수정	fix/token-expiration
refactor/	리팩토링 (기능 변경 없음)	refactor/user-service
docs/	문서 작업	docs/api-guide
test/	테스트 추가/수정	test/user-service
perf/	성능 개선	perf/query-optimization
chore/	설정, 의존성 등 잡무	chore/update-deps
hotfix/	프로덕션 긴급 수정 (main에서 분기)	hotfix/payment-error

기능명은 kebab-case로 작성합니다. (예: feature/social-login)

작업 흐름

1. 기능 개발

# develop 최신화
git checkout develop
git pull origin develop

# feature 브랜치 생성
git checkout -b feature/login-api

# 작업 & 커밋
git commit -m "feat: add login endpoint"

2. PR 생성 및 머지

1. {type}/기능명 → develop 로 PR 생성
2. 최소 1명 이상의 approve 필요
3. Squash and merge 로 머지
4. 머지 후 작업 브랜치 삭제

3. 배포

1. develop → main 으로 PR 생성
2. 리뷰 후 머지하면 배포

규칙 요약

항목	규칙
브랜치 네이밍	{type}/기능명 (kebab-case, 타입 표 참고)
PR 대상	작업 브랜치: develop / 배포: main
머지 방식	Squash and merge
리뷰	최소 1명 approve
머지 후	작업 브랜치 삭제

Hotfix (제안)

⚠️ 이 섹션은 팀 논의가 필요한 제안 사항입니다.

1. main에서 hotfix/이슈명 브랜치 분기
2. 수정 후 main으로 PR → 머지 (즉시 배포)
3. 동일한 변경을 develop에도 백머지하여 동기화