각 commit은 하나의 변경 이유를 담는 atomic commit으로 구성한다.
다른 변경은 유지하면서 특정 변경만 따로 되돌리는 것이 의미가 있다면 별도 commit으로 분리한다. 같은 기능이나 파일에 속하거나 여러 변경을 포괄하는 상위 목적이 같다는 이유만으로 하나의 commit에 묶지 않는다.
commit message는 Conventional Commits 1.0.0 형식을 따른다.
<type>[optional scope][optional !]: <description>
[optional body]
[optional footer(s)]
scope는 선택 사항이며, 변경된 코드베이스 영역을 설명하는 명사를 괄호 안에 적는다.- Breaking change는 콜론 앞의
!또는BREAKING CHANGE: <description>footer로 표시한다.!를 사용할 때는 description에서 하위 호환성을 깨는 변경을 명확하게 설명한다.
commit 단위를 먼저 결정한 뒤, 각 commit의 변경 목적에 따라 다음 type 중 가장 적절한 하나를 선택한다. type을 기준으로 변경을 묶거나 분리하지 않는다.
feat: 새로운 기능fix: 버그 수정refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경perf: 성능을 개선하는 코드 변경test: 누락된 테스트 추가 또는 기존 테스트 수정docs: 문서만 변경build: 빌드 시스템 또는 외부 의존성에 영향을 주는 변경ci: CI 구성 파일 및 스크립트 변경
이전 commit을 되돌릴 때는 다음 형식을 사용한다.
revert: <reverted commit header>
body에는 되돌리는 commit의 SHA와 되돌리는 이유를 반드시 기록한다.
This reverts commit <commit SHA>.
<reason for reverting the commit>
- 명령형으로 작성하고, 소문자로 시작하며, 마침표로 끝내지 않는다.
- 의미를 훼손하지 않는 선에서 가능하면 전체 header를 50자 이내로 작성한다.
- 변경 대상과 결과를 명확하게 설명하고,
update code,fix bug,make changes처럼 의미가 불분명한 표현을 피한다. - Issue 번호를 사용할 때는 무엇을 변경했는지도 함께 설명한다.
- 간단하고 자명한 변경에는
body를 생략할 수 있다. body에는 코드만으로 알기 어려운 배경과 판단 근거를 설명한다. 변경 전의 문제, 변경이 필요한 이유, 해결 방법을 선택한 이유, 중요한 제약, 트레이드오프 또는 검토 후 제외한 대안을 포함한다.- 코드나 diff를 그대로 반복하지 않는다. 외부 링크를 열지 않아도 핵심 내용을 이해할 수 있도록 설명한다.
- 가독성을 위해 약 72자에서 줄바꿈한다.