[공통] Git 컨벤션 - woowacourse-teams/2026-gachi-gacha GitHub Wiki

브랜치 전략

• main / feature 브랜치 구조를 기본으로 하되, 포지션별로 별도의 dev 브랜치를 둡니다.
  • backend-dev
  • frontend-dev
• 각 포지션의 작업 브랜치는 해당 포지션의 dev 브랜치를 기준으로 생성하고, PR도 해당 포지션의 dev 브랜치를 대상으로 올립니다.
  • 예: 백엔드 작업은 backend-dev에서 분기해 backend-dev로 PR
• 브랜치명: 타입/이슈번호-요약 (예: feature/1-map)
  • 브랜치명에 이슈 번호를 꼭 포함해, 브랜치 목록만 봐도 내용을 알 수 있게 합니다.

커밋 메시지

AngularJS Git Commit Message Conventions 기반으로 작성한다.

• subject: feat/fix/docs 등 타입은 원문 그대로 작성
• scope / body / title: 한글로 가독성 좋게 작성
• 커밋 메시지 본문에는 '무엇'보다 '왜'를 쓰기 (무엇은 diff가 이미 말해줌)

이슈·PR 워크플로우

진행 순서: 미팅 → 필요한 기능 논의 → 이슈 생성 (=요구사항) → 구현 → PR 생성 시 관련 이슈 연결

• 이슈는 요구사항 1개 = 이슈 1개 원칙, 1~3일 안에 끝내기 어려우면 쪼개기
• 이슈/PR 제목은 [FEAT] 지도에 가챠샵 마커 표시 형태로 통일
• 이슈 번호는 커밋이 아니라 PR에서 한 번만 연결
  • PR 본문 맨 아래에 Closes #12 작성
  • 닫을 이슈가 여러 개면 키워드를 반복 (Closes #12, #13은 #12만 닫힘)

머지 규칙

• 머지는 Squash and merge로 통일, 머지 후 브랜치 삭제
• 마지막 approve 한 리뷰어가 머지 버튼을 누름