Conventions

📝 Conventions

SMOOTH 프로젝트의 모든 저장소에서 공통으로 적용하는 규칙입니다.
👉 프론트엔드 / 백엔드 세부 규칙은 추후 필요 시 별도 문서로 분리합니다.

---

✏️ Commit 메시지

• 형식: prefix: 설명
• 예시:
  • feat: 주행 데이터 처리 로직 추가
  • fix: JWT 인증 오류 수정

Prefix 규칙

Prefix	설명
feat:	기능 추가/수정/삭제
fix:	버그 수정
refactor:	리팩토링 (로직 변경 없이 구조만 수정)
chore:	설정, 패키지 설치 등 코드 외 수정
test:	테스트 코드 추가/수정

---

🌿 브랜치 전략

SMOOTH 프로젝트는 Epic → User Story → Task 단위로 브랜치를 관리하며,
머지 이후 후속 작업에 대한 규칙도 별도로 둡니다.

• main

  • 안정화된 배포용 브랜치

• dev

  • 모든 User Story가 통합되는 개발 브랜치

• US<번호>

  • 유저 스토리 단위 개발 브랜치
  • 예: US5.1-realtime-alert

• T<에픽.유스.태스크>

  • Task 단위 작업 브랜치
  • 예: T5.1.4-filtering-logic

• 후속 작업

  • US 머지 이후 (아직 dev 머지 전)
    • feat/US<번호>-*, fix/US<번호>-*, refactor/US<번호>-*
    • 예: fix/US5.1-kst-timestamp
  • dev 머지 이후 (통합 후속작업)
    • fix-dev, refactor-dev, test-dev
    • 예: refactor-dev-redis-injection

---

🔀 Pull Request 규칙

• Task → US 브랜치 머지

  • # PR: T<에픽.유스.태스크> - <간단 요약> → <머지할 브랜치> 머지

• User Story → dev 머지

  • # PR: US<번호> - <간단 요약> → <머지할 브랜치> 머지

• US 후속 변경 (dev 전)

  • # PR: <prefix> - US<번호> <간단 요약> → <머지할 브랜치> 머지

• dev 후속 변경 (dev 통합 이후)

  • # PR: <prefix> - dev <간단 요약> → <머지할 브랜치> 머지
  • 예: # PR: refactor - dev Redis 주입 명시화 → DEV 머지

📌 상세 작성 가이드는 Pull Request Guide 문서를 참고하세요.