Git 커밋 메시지 컨벤션

최근에 커밋 메시지 또한 작업 내역을 파악하는 데에 굉장히 중요한 역할을 한다는 것을 깨달은 뒤

커밋 메시지도 좀 보기 좋게 작성해야겠다고 생각을 하고 있다.

 

요 근래에 계속해서 참고했던 커밋 메시지 컨벤션 관련 블로그 글을 

간단하게 정리해놓고 앞으로 계속해서 참고해가면서 커밋 메시지를 작성해야겠다.

습관을 들이다보면 언젠가는 찾아보지 않고도 몸에 익을거라고 생각한다.

 

커밋 메시지에 본문을 작성할 수 있다는 것도 최근에서야 알게 되었다.

윈도우에서는 커밋 메시지를 작성할 때 줄바꿈이 안돼서,

항상 git commit --amend를 사용해서 메모장을 켜서 본문을 작성하고 있는데

혹시 그러지 않고 cmd 창에서 작성할 수 있는 방법을 아시는 분이 있다면 알려주세용

---

■ 커밋의 종류

- feat: 새로운 기능 추가

- fix: 버그 수정

- docs: 문서 수정

- style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우

- refactor: 코드 리팩토링

- test: 테스트 코드, 리팩토링 테스트 코드 추가

- chore: 빌드 업무 수정, 패키지 매니저 수정

 

■ 제목

- 제목은 50자를 넘기지 않고, 대문자로 시작하고, 마침표를 붙이지 않는다.

- 과거 시제를 사용하지 않고, 명령형으로 쓴다.

ex) "Changed" → "Change"

 

■ 본문

- 본문은 선택사항. 꼭 적을 필요는 없다.

- 부연 설명이 필요할 경우.

- 커밋의 what과 why를 설명하는 데에 사용할 것. how는 필요 없음.

- 72자를 넘기지 말 것.

---

■ 헷갈리는 점

- 언제 어떤 키워드를 사용해야 하는지 명확하게 구분이 안 될때가 있긴 함.

특히 style과 refactor같은 경우는 그 기준을 아직까지는 확실히 모르겠어서, 그냥 refactor로 퉁칠 때가 많다.

이런 기준을 좀 더 명확하게 세우고 나면 더 구분이 잘 되는 커밋 메시지를 작성하는 게 가능해질 듯.

 

- 자잘한 변경사항들이 많은 경우, 그냥 한 번에 모아서 커밋하는 게 좋은지,

아니면 최대한 자잘자잘하게 전부 커밋을 하는 게 좋은지.

 

- 관련이 없는 것들끼리 하나의 커밋으로 모아놓고, 제일 큰 변경사항을 제목으로 하고

나머지를 본문에 풀어쓰는 식으로 커밋을 자주 했는데 사실 별로 안좋은 습관같긴 하다.

최대한 관련된 것들끼리 먼저 작업하도록 작업 순서 자체를바꿔야 하는건감?

---

참고

Udacity Nanodegree Style Guide

Git - 커밋 메시지 컨벤션