Git Workflow

Git Workflow

브랜치 전략, 커밋·PR·배포 규칙.

브랜치 전략

Git Flow + 연속 브랜치 파생 지원

• 작업 브랜치: feat/{이슈번호} 또는 bug/{이슈번호} (base: develop, PR 대상: develop)
• 연속 브랜치: feature에서 다음 feature 파생 가능 (티켓 단위 분리)
• PR 대기 중 작업: 승인 대기 중 이전 브랜치에서 다음 브랜치 생성 가능
• 동기화: develop에서 merge 대신 fetch + rebase 사용
• main/develop 직접 푸시 금지 — 반드시 PR을 통해 머지

배포 브랜치 전략

• TestFlight 배포: testFlight/{번호} 브랜치 생성 → testFlight으로 PR 머지
• Release 배포: release/{번호} 브랜치 생성 → release로 PR 머지
• 배포 브랜치는 develop에서 분기하여 번호를 순차적으로 매김
• 직접 푸시 금지, 반드시 PR을 통해 머지

커밋 형식

type: 작업 내용

커밋 메시지는 제목 한 줄 + 빈 줄 + 변경사항 bullet list 형식으로 작성합니다.

Type	용도
feat	새 기능
fix	버그 수정
refactor	리팩토링
docs	문서
chore	기타
test	테스트
design	UI/디자인 시스템

⚠️ 커밋 메시지에 Co-Authored-By 라인을 절대 추가하지 않습니다.

PR 규칙

• 최소 1인 Approve 필수
• main/develop 직접 푸시 금지
• 기본 머지 방식: Squash and Merge
• 배포 PR 예외: testFlight, release 브랜치로의 PR은 Merge Commit 사용 (커밋 히스토리 동기화)
• UI 변경 시 스크린샷/영상 첨부
• PR 본문 최소 항목: 작업 내용 / 변경 이유 / 리뷰 포인트 / 추후 작업

---

관련 문서: Coding Conventions · Build & Run