[git] git commit message convention

• https://www.youtube.com/watch?v=OJqUWvmf4gg
• https://github.com/pvdlg/conventional-commit-types
• https://www.conventionalcommits.org/ko/v1.0.0/
• https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

---

내가 작성한 커밋을 누군가 나중에 봤을 때 어떤 의미인지 잘 파악할 수 있도록 작성해야 함. 커밋 메시지 작성 방법은 집단마다 다를 수 있지만(협업 툴에서 정의한 작업 번호를 사용하는 등), 공통적으로 특정 커밋이 어떤 의미로 수행된 것인지 파악하기 쉽게 작성하는게 중요하다.

커밋 메시지 구조

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

type

커밋의 의도를 설명하는 부분. 어떻게 사용하든 상관 없지만, 사람들이 자주 사용하는 키워드 리스트는 존재한다.

키워드	설명
feat	사용자를 위한 새로운 기능 추가
fix	사용자를 위한 버그 수정
docs	문서만 변경된 경우
style	코드와 관계 없는 스타일 측면 변경사항 ( 공백 / 탭 / 세미콜론 등 )
refactor	코드 리팩토링(변수 이름 변경 등)
test	테스팅 코드
chore	문서 생성과 같은 빌드 프로세스 또는 보조 도구 및 라이브러리에 대한 변경. chore의 경우 커버하는 범위가 넓어서 이를 세분화하는 경우도 있는 것 같다. ci: ci 구성 파일이나 스크립트 수정(github action / travis 등) build: 빌드 시스템, 외부 종속성 변경 등에 의한 사항들
revert	커밋 되돌리기

description

이 커밋이 무엇을 하는지 설명하는 짧은 메시지. 헤더 부분에서 한 줄 띄고 작성

• 최대한 현재형으로 ( adds, added 보다는 add )
• 글자 수는 50자 이내로 ( 구체적으로 써야 하면 body에 작성 )

body

커밋에 대한 상세 메시지. description만으로도 충분하다면 굳이 작성할 필요 X

• 왜 이런 변경사항을 진행했는지 나중에 보고 이해할 수 있는 수준으로 작성
• 따로 규격은 없으나, 간결하게 작성

footer

이슈 추적 등을 목적으로 작성. 필요하지 않다면 꼭 작성할 필요는 없음.

어떤 커밋에서 발생한 문제를 해결했는지, 연관된 커밋은 무엇인지와 같은 정보를 해시태그 등 방법으로 표현한다.

---

내가 봐도 내 커밋의 의미를 해석하기 어려운 경우가 많았는데, 이런 문제가 발생하지 않도록 최대한 커밋에 의미를 담을 수 있게 노력해야겠다.