Pull Request Guide

🔀 Pull Request Guide

이 문서는 SMOOTH 프로젝트의 PR 작성 규칙과 템플릿을 정리한 가이드입니다.
모든 팀원은 PR 생성 시 본 문서를 참고하여 일관성을 유지해야 합니다.

---

🏷️ PR 제목 규칙

Task → User Story 브랜치 머지

• 형식:
  # PR: T<에픽.유스.태스크> - <간단 요약> → US<번호> 머지
• 예시:
  # PR: T5.1.4 - 반경 기반 유저 필터링 로직 구현 → US5.1 머지

---

User Story → dev 브랜치 머지

• 형식:
  # PR: US<번호> - <간단 요약> → dev 머지
• 예시:
  # PR: US5.1 - 실시간 사고 알림 기능 구현 완료 → dev 머지

---

후속 변경 (US/dev)

• 형식:
  • # PR: <prefix> - US<번호> <간단 요약>
  • # PR: <prefix> - dev <간단 요약>
• prefix 목록:
  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • refactor: 기능 변화 없는 코드 개선
  • chore: 설정/환경/빌드 등 부수적 작업
  • test: 테스트 코드 관련 변경
  • hotfix: 긴급 버그 수정
• 예시:
  • # PR: fix - US5.1 KST 타임스탬프 파싱 적용
  • # PR: refactor - dev Redis 주입 명시화

---

📄 PR 본문 템플릿

PR 작성 시 아래 템플릿을 복사해 사용합니다.

# PR: <규칙에 맞는 제목>

## 목적
- 이 PR이 필요한 이유 또는 배경을 간단히 작성합니다.
- (예: KST 시간 파싱 오류 수정, 실시간 알림 기능 구현, Redis 구조 리팩토링 등)

---

## 구현/변경 사항
- <주요 기능/코드 변경 1줄 요약>
- <주요 기능/코드 변경 1줄 요약>
- (Task → US 머지일 경우 하위 Task 번호와 설명을 목록화)

---

## 테스트 (있을 경우만 작성)
- <테스트 환경> (예: Docker 기반 로컬 환경, staging 서버 등)
- <테스트 방법> (예: REST API 호출, WebSocket 연결, 단위 테스트 실행 등)
- <검증 결과> (예: 메시지 수신 정상, 반경 필터링 성공, 예외 처리 통과 등)

---

## BREAKING CHANGE (있을 경우만 작성)
- <호환성 깨짐 / API 변경 / 클라이언트 수정 필요 사항>
- (예: `/user/{userId}/alert` → `/user/queue/alert` 변경, timestamp 포맷 KST 필수 등)

---

## 참고
- 관련 이슈/유저 스토리: Refs: US<번호> (또는 Task 번호)
- 기타 후속 작업이나 주의사항
- (예: JWT 인증은 추후 연동 예정, 로깅 레벨은 임시 상향 조정 등)