규칙에 맞는 좋은 커밋메시지를 작성해야 하는 이유는?
Commit message 구조
Type
Tag Name | Description |
---|
Feat | 새로운 기능을 추가 |
Fix | 버그 수정 |
Design | CSS 등 사용자 UI 디자인 변경 |
!BREAKING CHANGE | 커다란 API 변경의 경우 |
!HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
Style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 |
Refactor | 프로덕션 코드 리팩토링 |
Comment | 필요한 주석 추가 및 변경 |
Docs | 문서 수정 |
Test | 테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음 |
Chore | 빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음 |
Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
Remove | 파일을 삭제하는 작업만 수행한 경우 |
Subject
- Type 과 함께 헤더를 구성합니다. 예를들어, 로그인 API 를 추가했다면 다음과 같이 구성할 수 있습니다.
ex) feat: Add login api
Body
- 헤더로 표현이 가능하다면 생략이 가능합니다. 아닌 경우에는 자세한 내용을 함께 적어 본문을 구성합니다.
- 어떠한 이슈에 대한 commit 인지 issue number 를 포함합니다.
- 이슈 트래커 유형은 다음 중 하나를 사용한다.
- Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
- Resolves: 이슈를 해결했을 때 사용
- Ref: 참고할 이슈가 있을 때 사용
- Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
Example
Feat: 회원 가입 기능 구현
SMS, 이메일 중복확인 API 개발
Resolves: #123
Ref: #456
Related to: #48, #45