2025 상명대학교 캡스톤 디자인 백엔드 레포지토리 입니다.
효율적인 협업과 프로젝트 관리를 위해 다음과 같은 커밋 규칙을 따르기
커밋 메시지는 다음 구조를 따릅니다:
<type>(<scope>): <subject>
<body>
<footer>
커밋의 유형을 나타내며, 다음 중 하나를 선택합니다:
feat: 새로운 기능 추가fix: 버그 수정docs: 문서 수정style: 코드 형식 변경 (코드 로직에 영향을 주지 않는 변경)refactor: 코드 리팩토링test: 테스트 코드 추가 또는 수정chore: 빌드 프로세스 또는 보조 도구 변경perf: 성능 개선ci: CI 설정 파일 및 스크립트 변경revert: 이전 커밋으로 되돌리기
변경이 영향을 미치는 범위를 나타냅니다. 예: auth, navbar, api
- 변경 사항을 간결하게 설명합니다.
- 명령문 형태로 작성합니다. (예: "변경", "추가", "수정" 등으로 시작)
- 첫 글자는 소문자로 작성합니다.
- 끝에 마침표(
.)를 사용하지 않습니다.
- 변경 이유와 변경 내용을 자세히 설명합니다.
- 여러 줄로 작성 가능합니다.
- Breaking Changes: 호환성을 깨뜨리는 변경사항 명시
- Closed Issues: 해결된 이슈 번호 명시 (예:
Closes #123, #456)
feat(auth): 소셜 로그인 기능 추가
- Google과 Kakao 소셜 로그인 구현
- 유저 프로필 정보 연동 및 DB 저장 로직 추가
Closes #123, #456
fix(api): 회원 인증 토큰 만료 버그 해결
- 토큰 갱신 로직 수정
- 잘못된 예외 처리 로직 개선
Closes #789
docs(readme): 프로젝트 설치 가이드 업데이트
docs(api): 엔드포인트 명세서 수정
refactor(auth): 로그인 로직 모듈화
- 중복된 코드를 제거하고 함수 재사용성을 높임
test(user): 회원가입 단위 테스트 추가
- Edge case를 고려한 테스트 케이스 작성
- 논리적 단위로 커밋 나누기: 하나의 커밋에는 하나의 논리적 변경사항만 포함합니다.
- 자주 커밋하기: 작업 내용을 잃지 않도록 작은 단위로 커밋합니다.
- 커밋 전 코드 리뷰하기:
git diff명령어를 사용하여 변경사항을 다시 한 번 확인합니다. - 테스트 통과 확인: 커밋하기 전 모든 테스트가 통과하는지 확인합니다.
- 브랜치 전략 준수: 팀에서 정한 브랜치 전략(예: Git Flow, GitHub Flow)을 따릅니다.
- 영어로 커밋 메시지 작성하기: 국제적인 협업과 오픈소스 기여를 고려합니다.
- 현재형으로 작성하기: "Added feature"가 아닌 "Add feature"로 작성합니다.
- 50자 이내로 간결하게 작성하기: 커밋 메시지의 가독성을 높입니다.
- 관련 이슈 번호 참조하기: 커밋 메시지에 관련 이슈 번호를 포함합니다 (예:
Closes #123).
- 코드 포맷팅 확인
- 린트 검사 통과
- 테스트 코드 실행
- 불필요한 콘솔/주석 제거