커밋 메세지를 작성하는데 하나의 룰을 정하고 개인/팀 내에서 같이 사용한다면,
나중에 Commit 메시지 만으로도 어떤 수정 사항이 발생하였는지 파악하기 쉬울 것입니다.

어떤 룰을 사용할까

좋은 룰은 파악하기 쉽도록 명확한 메세지를 작성해야 합니다.

좋은 룰에 정답은 없지만, 많은 사람들이 사용하는 형식은 있습니다.

검색 중에 Udacity Git Commit Message Style Guide 커밋 가이드를 찾을 수 있었습니다.

메세지 구조

커밋 메세지의 구조는 Subject, Body, Footer세 부분으로 나뉘며,
각 부분을 한 줄의 공백으로 구분합니다.

한 줄의 공백으로 구분하면, git log의 --online 옵션을 사용할 때,
요약 메세지를 작성하는 Subject 부분만 확인할 수 있습니다.

만약, 공백으로 구분하지 않았다면 모든 메세지가 한 줄로 출력됩니다.

type : [#issueNumber - ] Subject

body

footer

제목 (Subject)

type : [#issueNumber - ] Subject

커밋에 대한 주요 내용을 간결하고 명확하게 작성합니다.

• 원문에 명령조로 작성하라고 되어있지만, 이는 영어에 한합니다.
• 한글로 작성할 때는, 구문 형태로 작성하면 간결합니다. 회원 생성 서비스 추가

제목은 항상 입력해야 하며,type과 함께 작성되어야 합니다.

제목은 최대 50자를 넘지 않도록 주의합니다.

제목의 마지막에 마침표(.)를 찍지 않습니다.

Type

Type은 항상 영문 소문자로 작성합니다.

Type의 종류를 Udacity Style Guide에선 7가지로 정의하고 있습니다.

• feat : 새로운 기능을 추가하거나, 기존 기능을 요구사항 변경으로 인해 변경한 경우
• fix : 버그를 수정한 경우
• docs : 문서(주석) 추가/수정의 경우, 직접적인 코드의 변화 없이 문서만 추가 수정 했을 때
• style : UI를 추가/수정하거나, 스타일 관련 작업의 경우
• refactor : 기능의 변경 없이, 코드를 리팩토링 한 경우
• test : 테스트 코드를 추가/수정한 경우
• chore : 기능/테스트, 문서, 스타일, 리팩토링 외에 배포, 빌드와 같이 프로젝트의 기타 작업들에 대해 추가/수정한 경우

기능 추가와 수정을 나누고 싶을 때는, feat를
기능 추가 : new ,
기능 수정 : imporve로 나누어도 좋습니다.

리팩토링 : 결과의 변경 없이 코드의 구조를 개선합니다.
코드의 가독성을 좋게 하도록, 변수명이나 내부 로직을 변경합니다.

body

body 부분은 생략 가능합니다.

커밋한 상세 내역을 작성합니다.

본문의 내용은 '어떻게' 보다는 '무엇을', '왜' 에 맞춰서 작성합니다.

• 무엇을 왜 고쳤는지에 대한 내용이 코드의 변경 의미를 파악하는데 더욱 도움이 됩니다.

footer

footer 부분은 생략 가능합니다.

해당 커밋과 연관된 이슈 트래킹 번호를 입력합니다.

제목에 이슈 번호를 추가 할 때는, 한개의 이슈에 해당할 때만 사용하고,
그 외에는 footer에 이슈 번호를 라벨과 추가합니다.

라벨의 종류에는 Resolve, closes, Fixes, see also가 있는데,
github의 경우 라벨의 내용에 따라서 이슈를 닫을 수 있습니다

참고 블로그

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

Git Commit Message Style Guide - 개인/팀을 위한 커밋 메시지 스타일 가이드