본 프로젝트는 효율적인 협업과 코드 품질 유지를 위해 Git 커밋, 브랜치 전략, PR 및 이슈 규칙을 준수합니다.
모든 작업은 이슈를 생성하는 것에서 시작하며, 작업 단위를 명확히 합니다.
- 이슈 제목:
#이슈번호 [TYPE] 작업 내용 요약형식으로 작성합니다. (예:#01 [FEAT] 로그인 API 개발) - 이슈 템플릿: 작업 성격에 맞는 템플릿을 선택하여 작성합니다.
- Feature: 새로운 기능 요구사항 정의
- Bug: 버그 발생 상황 및 재현 방법 설명
- 할 일 목록: 이슈 본문에 작업해야 할 체크리스트를 포함합니다.
- 라벨(Labels): 이슈 성격에 맞는 라벨을 지정하여 관리합니다. (예:
enhancement,bug,refactor)
커밋 메시지는 Angular Commit Message Guidelines를 기반으로 작성합니다.
<type>: <subject> <-- 제목 (필수)
<body> <-- 본문 (선택)
<footer> <-- 바닥글 (선택)
| 타입 | 의미 |
|---|---|
feat |
새로운 기능 추가 |
fix |
버그 수정 |
docs |
문서 수정 (README, Swagger, 주석 등) |
style |
코드 포맷팅, 세미콜론 누락 등 (로직 변경 없음) |
refactor |
코드 리팩토링 |
test |
테스트 코드 추가 및 수정 |
chore |
빌드 업무, 패키지 설정, 의존성 추가 (gradle 등) |
config |
설정 파일 수정 (application.yml 등) |
- 제목은 50자 이내로 요약하며, 끝에 마침표(
.)를 찍지 않습니다. - 제목의 첫 글자는 대문자로 시작하며, 과거 시제가 아닌 명령문 형식을 사용합니다.
- 본문은 '무엇을', '왜' 변경했는지 상세히 설명합니다.
프로젝트의 안정성을 위해 Git Flow를 간소화한 전략을 사용합니다.
main: 프로덕션 환경에 배포되는 최상위 브랜치.dev: 다음 출시 버전을 개발하는 통합 브랜치.feature/: 새로운 기능을 개발하는 브랜치 (예:feature/login,feature/order).fix/: 급한 버그를 수정하는 브랜치 (예:fix/error-handler).refactor/: 코드 리팩토링을 진행하는 브랜치.
모든 코드는 PR을 통해 dev 브랜치에 병합됩니다.
- PR 제목:
[TYPE] 기능 요약형식으로 작성합니다. (예:[FEAT] 카카오 로그인 기능 구현) - 이슈 연결: 본문에
Closes #이슈번호를 기재하여 관련 이슈를 자동으로 종료합니다. - 최소 승인: 병합 전 최소 1명 이상의 팀원에게 Approve를 받아야 합니다.
- 코드 리뷰: 리뷰어는 변경 사항을 확인하고 피드백을 남기며, 작성자는 모든 피드백에 대응한 후 병합합니다.
- 빌드가 성공적으로 완료되었는가?
- 작성한 테스트 코드가 통과되었는가?
- 불필요한 로그나 주석을 제거했는가?
feat: 이메일 중복 체크 API 구현fix: 결제 시 간헐적으로 발생하는 NullPointerException 수정docs: API 가이드 문서에 인증 방식 설명 추가