Udacity의 커밋 메세지 스타일 가이드를 참조하였습니다.
커밋 메시지는 크게 제목, 본문, 꼬리말 세 가지 파트로 나누고, 각 파트는 빈줄을 두어서 구분합니다.
제목 (Type, Subject)
- 어떤 의도인지 짧게 설명
- : 뒤에만 space가 있음
type: subject
Type
- 기능
- feat : 새로운 기능 추가
- fix : 버그 수정
- design : UI 디자인 변경 (css 등)
- 개선
- style : 코드 수정 없음 (세미콜론 누락, 코드 포맷팅 등)
- refactor : 리펙토링
- comment : 주석 추가 및 변경
- 기타
- docs : 문서 수정 (README.md 등)
- test : 테스트 코드 추가
- chore : 빌드 업무 수정, 패키지 매니저 수정 (pom.xml 등)
- rename : 파일명, 폴더명 수정 또는 이동
- remove : 파일 삭제
Subject
- 동사 원형으로 시작
- 영어일 경우 첫 글자는 대문자
- 50자 이내로 작성
- 마지막에 특수문자 X (마침표, 느낌표 등)
본문 (Body)
- 무엇을 왜 했는지 설명
- 한 줄 당 72자 이내로 작성
- 최대한 상세히 작성
꼬리말 (Footer)
- 필수가 아닌
optional issue tracker ID를 명시하고 싶은 경우에 작성유형: #이슈 번호
- ex) Fixes: #23- 유형 종류
- Fixes: 이슈 수정중 (아직 해결되지 않은 경우)- Resolves: 이슈를 해결했을 때 사용
- Ref: 참고할 이슈가 있을 때 사용
- Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
Udacity 예시
feat: Summarize changes in around 50 characters or less More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here If you use an issue tracker, put references to them at the bottom, like this: Resolves: #123 See also: #456, #789
