Git commit message convention

Git 커밋 메시지 컨벤션을 찾아보면서 다양한 커밋 메시지 컨벤션이 존재하는 것을 알았다. 

그래서 검증되지 않은 블로그나 사이트를 참고 하지 않으려 했다.

특히 어디에서는 제목 첫 글자는 대문자 사용하지 말라하며 어느 곳에서는 대문자를 사용하라고 한다. 그러니 그냥 속한 팀의 convention을 따르는 것이 1순위인 것 같다.

나는 ConventionalCommits.org라는 152명의 contributer로 이루어진 곳을 참고했으며, NHN Meetup!에 있는 글을 참고하였다.

 

1. git 커밋 메시지를 잘 쓰려고 노력해야 하는 이유

 - 커밋 로그 가독성을 높인다.

 - 더 나은 협업과 리뷰 프로세스

 - 더 쉬운 코드 유지보수

 git log을 통해 여러 커밋 메시지를 확인하면 과거 어떤 코드를 변경했는지 이해하기 어려울  수 있다. 협업할 때는 더욱더 그렇기 때문에 개발과 협업을 더 효과적으로 만들어 준다.

 

2. 좋은 git 커밋 메시지를 작성하기 위한 약속

(1) 커밋의 Type를 명확히 하기.

• fix : 버그 해결 시
• feat : 새로운 기능 추가할 때.
• docs: 문서 수정 (documentation 관련 모든 것)
• style : 스타일링에 관련된 기능과 업데이트 시
• refactor : 코드 베이스 특정 섹션을 리펙토링 시 (버그 수정이나 기능 추가가 아닐 때)
• test : 테스트 코드, 리팩토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정.
• perf : 성능을 향상시키는 코드

(2) 제목과 본문을 한 줄 띄워 분리하기.

제목과 본문 사이 공백 한 줄을 통해 분리하면 git log --oneline 명령어 사용 시 제목만 보여준다

git shortlog 명령어를 통해 로그 확인 시에도 가독성을 더 높여준다.

 

(3) 제목은 영문 기준 50자 이내로

(4) 제목 첫 글자는 대문자로

(5) 제목 끝에 마침표 금지

(6) 제목은 명령조로

첫 단어를 동사원형으로 쓰기. 대신 본문 작성 시 평서문으로 작성한다.

 

(7) 본문은 영문 기준 72자마다 줄 바꾸기

(8) 본문은 '어떻게' 보다 '무엇을', '왜'에 맞춰 작성하기.

 

3. 커밋 메시지 구조

커밋 메시지의 구조는 다음과 같다.

<type>[optional scope]: <description> [optional body] [optional footer(s)]

4. SPECIFICATION 번역 - ConventionalCommits.org

커밋 메시지는 세 개의 다른 구조인 subject, body, footer로 이루어져 있으며 blank line으로 구분된다.

1. 커밋은 feat, fix 같이 반드시 명사로 이루어진 type으로 시작되어야 하고 optional한 scope와 ! 다음 반드시 :과 공백한칸이 존재해야 한다.

2. feat 타입은 커밋이 새로운 feature를 너의 어플리케이션이나 라이브러리에 추가할 때 반드시 사용되어야 한다.

3. fix 타입은 커밋이 어플리케이션에 대한 버그를 고치는 것을 나타낼 때 반드시 사용되어야 한다.

4. scope은 반드시 코드베이스의 section을 묘사하는 명사로 이루어져야 하며, 괄호로 감싸야한다. 예) fix(parser)

5. description은 반드시 type/scope 이후 콜론과 공백 다음 와야 하며 description은 코드 변경에 대한 짧은 요약이다.

에 ) fix: array parsing issue when multiple spaces were contatined in string

6. 짧은 description 이후 더 긴 커밋 body가 올 수 있는데, 코드 변경에 대한 추가 컨텍스트 정보를 제공한다.

 body는 description이후 반드시 하나의 공백 라인으로 시작해야 한다.

7. 커밋 body는 자유 양식이며 여러 단락으로 이루어질 수 있다.

8. 하나 이상의 footer가 body 다음 한 공백 라인 이후 존재할 수 있는데, 각 footer는 반드시 단어 토큰으로 이루어져야 하며 :<space> 나 <space># 구분자가 그다음 오고, 그 뒤에 문자열 값이 와야 한다.

9. footer의 token은 반드시 - 을 공백 문자 자리에 사용해야 하며 BREAKING CHANGE는 예외가 된다.

10. footer의 값은 공백과 새로운 줄을 포함할 수 있고, 다음 유효한 footer 토큰/구분자가 관찰될때 반드시 parsing이 종료되어야 한다.

11. 주요 변경사항(breaking change)들은 반드시 type/scope로 시작하는 커밋이나 footer 항목으로 반드시 표기되어야 한다.

12. footer로 만약 포함된다면, 주요 변경사항(breaking change)는 반드시 대문자 BREAKING CHANGE로 이루어져야 하며 콜론과 공백, description이 따른다

예)  BREAKING CHANGE: environment variables now take precedence over config files.

13. type/scope에 포함된다면, 주요 변경사항들은 반드시 콜론 직전에 ! 로 표기되어야 한다. 만약 ! 가 사용되면, BREAKING CHANGE: 는 footer에서 생략될 수 있으며 커밋 description은 breaking change를 나타내는 데 사용할 수 있다.

14. feat와 fix가 아닌 타입이 커밋 메시지에 사용될 수 있다.

15. Conventional Commit을 이루고 있는 정보 단위는 반드시 대문자여야 하는 BREAKING CHANGE를 제외하고 대소문자를 구분하는 것으로 처리되어서는 안 된다.

16. footer의 토큰으로 사용될 때,  BREAKING-CHANGE는 BREAKING CHANGE와 동의어이다.

 

* BREAKING CHANGE : footer에 BREAKING CHANGE:를 입력하거나, type/scope 다음 !를 붙임으로써  주요 API 변경사항 도입 시 사용하며 어떤 타입 다음에도 올 수 있음.

* fix:, feat: 이외에도 build: , chore: , ci: , docs: , style: , refactor: , perf: , test: 등을 사용하기를 추천합니다.

 

Reference : 

https://www.conventionalcommits.org/en/v1.0.0/

Conventional Commits

https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/

How to Write Good Commit Messages: A Practical Git Guide

https://meetup.toast.com/posts/106

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : NHN Cloud Meetup

https://dev.to/i5han3/git-commit-message-convention-that-you-can-follow-1709

Git commit message convention that you can follow!