(Git) 커밋 메시지 컨벤션

 

 

 

그동안 혼자서 작업했기에 git의 commit 메시지를 신경 쓰지 않았는데

 

협업 시에는 commit 메시지가 중요해질 것 같아서 commit 메시지의 컨벤션을 조사해 보았다.

 

다양한 컨벤션이 있었고, 이번 포스팅은 아래 가이드들을 참고해 정리했다.

 

commit-messages-guide/README_ko-KR.md at master · RomuloOliveira/commit-messages-guide

 

커밋 메시지 가이드  |  Blockly  |  Google for Developers

 

 

 

 

커밋 메시지의 목적

 

커밋 메시지의 목적은 다음과 같다. 

• 변경 사항을 이해하는데 도움을 주기 위해서 
• 코드 의도를 설명하기 위해 
• 문제 해결과 디버깅을 쉽게 하기 위해

커밋의 의도를 명확하게 할수록, 내가 무엇을 하려고 했는지가 명확해지며, 이에 다른 사람이 pull 요청을 검토하기가 수월하다.

 

즉 커밋 메시지는 소스코드의 변경사항을 잘 요약해야 하고, 내가 무엇을 의도했는지 단번에 파악할 수 있어야 한다.

 

 

 

 

커밋 형식

커밋의 형식은 아래와 같다. 

<type>: <description>

[optional body]

[optional footer(s)]

 

 

 

 

type 

prefix라고도 불린다. 항상 소문자로 작성해야 하며, 아래와 같은 키워드들이 있다.

 

+ 기존 코드와의 호환성을 깨뜨리는 변경사항(breaking changes)이 있는 경우 type 앞에! 를 붙인다. 

breaking changes 예시 
- 기존 함수의 시그니처(매개변수의 개수, 타입 등)가 변경되는 경우
- 기존 함수나 클래스의 동작 방식이 변경되는 경우
- 기존 함수나 클래스가 완전히 제거되는 경우

 

 

[코드 관련]

• chore : 환경설정, 의존성 업데이트 등 루틴 한 작업들을 한 경우
• feat : 새로운 기능을 추가한 경우
• fix : 버그를 수정한 경우
• refactor : 기능의 변경 없이, 코드를 리팩토링 한 경우
• deprecate : 특정 기능의 사용을 중지하는 경우

 

[릴리즈 / 테스트/ 스타일 / 문서]

• release : 새 버전을 릴리스하는 것과 관계가 있는 경우
• test : 테스트 코드를 추가/수정한 경우
• docs : 문서나 주석을 추가/수정하는 경우
• style :  스타일 관련 작업의 경우

 

 

 

description

상세한 커밋 메시지를 작성하는 부분, type과 마찬가지로 필수이며, 256글자를 넘어가면 안 된다.

 

아래 규칙을 지키면 명확한 메시지를 작성할 수 있다.

 

1. 명령조 사용하기
2. 소스코드를 보지 않고도 변경 사항이 무엇인지 알 수 있게 하기
3. 커밋 메시지 본문으로 "why", "what", "how"를 포함하기 & 상세 내용 추가

 

 

 

optional body

선택사항으로 더 자세한 정보를 제공할 필요가 있을 때 사용한다. 

 

type : description 다음으로 한 줄을 띄고 난 다음에 사용하거나 full request 설명에 작성한다.

 

 

 

 

footer

선택사항으로 해당 커밋과 연관된 이슈 트래킹 번호와 라벨을 추가한다.

 

라벨의 종류에 대해서는 gitdoc에서 자세히 나와있다. 

 

Managing labels - GitHub Docs