원활한 협업과 기록 관리를 위해 아래의 커밋 컨벤션 따른다.
커밋 메시지는 다음의 형식을 따라 작성한다.
<Emoji> <Type>: <Subject>
<Body> (Optional)
<Footer> (Optional)
커밋의 종류를 나타내며, 아래 타입 중 하나를 사용합니다. 커맨드 라인에서 이모티콘 깨짐을 방지하려면 실제 이모티콘 대신 Emoji Code를 사용한다.
Feat✨ (:sparkles:): 새로운 기능 추가 또는 기존 기능 개선Fix🐞 (:bug:): 버그 수정 (서버 오류, 데이터 불일치 등)Docs📚 (:books:): 프로젝트 문서 수정 및 추가 (README.md 등)Style🎨 (:art:): 코드 포맷팅, 세미콜론 누락 등 기능과 무관한 스타일 수정Refactor🔨 (:hammer:): 기존 코드 및 아키텍처 개선 (리팩토링)Test✅ (:white_check_mark:): 유닛 테스트, 통합 테스트 코드 추가 및 수정Chore⚙️ (:gear:) : 개발 환경 구축 및 설정 변경 사항 (빌드, 의존성 업데이트 등)Devops🐳 (:whale:): 배포, CI/CD 및 프로젝트 자동화 관련Security🔒 (:lock:): 보안 관련 작업
- 제목은 50자 이내로, 무엇을 했는지 명확하게 요약한다.
- 문장의 끝에 마침표(
.)를 찍지 않는다. Feat: 로그인 기능 구현과 같이 명령문으로 작성한다.
- 본문은 선택 사항이며, 제목만으로 설명이 부족할 때 작성한다.
- 어떻게 변경했는지, 왜 변경했는지에 대해 상세히 서술한다.
- 줄 바꿈이 필요할 경우, 한 줄에 72자 이내로 작성한다.
꼬리말은 관련된 이슈 번호를 명시할 때 사용한다. 아래 키워드를 사용하면 PR 병합 시 연결된 이슈를 **자동으로 종료(close)**시킬 수 있다.
| 키워드 | 주된 사용 규칙 | 사용 예 |
|---|---|---|
Closes |
기능 구현, 작업 완료 등 일반적인 이슈를 해결했을 때 사용한다. | Closes #10 |
Fixes |
버그(Bug)를 수정하여 이슈를 해결했을 때 사용한다. | Fixes #25 |
Resolves |
기능/버그 외 논의가 필요했던 이슈를 해결했을 때 사용한다. | Resolves #40 |
Note: 이슈를 자동으로 종료시키지 않고 단순히 참조만 할 경우, 키워드 없이 이슈 번호만
#과 함께 적는다. (예:이 커밋은 #75 이슈와 관련이 있습니다.)
✨ Feat: 소셜 로그인 기능 구현
- OAuth 2.0을 이용한 구글, 카카오 로그인 기능 추가
- 로그인 성공 시 JWT 토큰 발급 로직 구현
Closes #123
🐞 Fix: 메인 페이지 데이터 조회 오류 수정
- 비동기 처리 과정에서 발생하던 데이터 누락 문제 해결
- API 응답 값 변경에 따른 타입 정의 수정
Fixes #45
🔨 Refactor: 중복된 인증 로직을 유틸리티 함수로 분리
- 여러 서비스에서 사용되던 인증 관련 코드를 `auth.util.ts`로 통합
- 코드 재사용성을 높이고 유지보수 용이성 개선
#80 이슈 논의를 바탕으로 리팩토링 진행
모든 브랜치는 develop 브랜치에서 생성하는 것을 원칙으로 한다.
브랜치 이름은 작업의 성격과 이슈 번호를 조합하여 다음 규칙을 따른다.
{label}/{issue-number}
⚠️ 주의: 브랜치 이름에 # 문자를 포함하지 않는다.
터미널 명령에서 오류를 유발할 수 있다.
| 라벨 | 브랜치 이름 예시 | 설명 |
|---|---|---|
| Feature | feature/123 |
이슈 #123의 새로운 기능 개발 |
| Bug | bug/45 |
이슈 #45의 버그 수정 |
| Refactor | refactor/80 |
이슈 #80 관련 코드 리팩토링 |
| Docs | docs/7 |
이슈 #7 문서 수정 및 추가 |
| Test | test/99 |
이슈 #99 테스트 코드 추가/수정 |
| Chore | chore/22 |
이슈 #22의 설정, 빌드 관련 작업 |
| Devops | devops/18 |
배포 자동화, CI/CD 관련 작업 |