Git - Commit Message Convention
커밋 메시지를 작성할 때는 원칙을 정하고 일관성 있게 작성해야 한다. 깃을 통한 협업을 진행할 때, 커밋 메시지를 보고 팀원들끼리 무슨 작업을 했는지 명확하게 확인할 수 있다면 보다 효율적인 협업이 이루어 질 수 있다. 아래는 유다시티의 커밋 메시지 스타일 가이드를 참조한 내용이다.
커밋 메시지 구조
커밋 메시지는 빈 줄로 구분된 세 부분으로 구성됩니다. 제목, 선택적인 본문 및 선택적인 바닥글입니다. 레이아웃은 아래와 같습니다.
type: Subject
body
footer제목은 메시지의 유형과 제목으로 구성됩니다.
유형
- feat: 새로운기능
- fix: 버그수정
- docs: 문서 변경 사항
- style: 서식 지정, 세미콜론 누락 등 코드 변경 없음
- refactor: 프로덕션 코드 리팩토링
- test: 테스트 추가, 테스트 리팩토링; 생산 코드 변경 없음
- chore: 빌드 작업 업데이트, 패키지 관리자 구성 등 생산 코드 변경 없음
제목
제목은 50자 이하여야 하며 대문자로 시작하고 마침표로 끝나지 않아야 합니다.
커밋이 무엇을 했는지보다 명령형을 사용하여 커밋이 하는 일을 설명합니다.
본문(body)
모든 커밋이 본문을 보증할 만큼 복잡하지는 않으므로 선택 사항이며 커밋에 약간의 설명과 컨텍스트가 필요한 경우에만 사용됩니다. 본문을 사용하여 커밋의 내용과 이유를 설명하는 것이 아니라 방법을 설명합니다.
본문을 작성할 때 제목과 본문 사이에는 빈 줄이 있어야 하며 각 줄의 길이는 72자 이내로 제한해야 합니다.
바닥글(footer)
바닥글은 선택 사항이며 issue를 추적할 때 사용합니다.
커밋 메시지 예시
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