참고문서
KazanExpress님의 Github
필요성
커밋에 대한 정보를 체계적인 규칙을 가지고 쓴다면 남이 보기도 편하고 내가 보기도 편해진다. 게다가 작업 단위로 커밋을 작성하기 때문에 버전을 바꾸기에도 더 수월하다.(checkout하기도 수월)
커밋 메세지의 구조
제목, 본문, 꼬릿말 세 부분으로 나뉘고 필수적으로 작성해야 하는 부분은 제목이다. 본문과 꼬릿말 부분은 생략가능한 부분이라고 한다.
1. 제목
제목은 type과 subject로 이루어져 있다.
type에 적을 수 있는 유형
Fix - 버그 수정
Feature - 새로운 기능 추가
Update - 일반적인 업데이트
버전 업데이트
Chore - 다른 유형에 속하지 않는 것.
최종 파일에 해당 변경 사항을 포함하지 않고 싶을 때 선택
Refactor- 코드/구조 리팩토링. 파일 이름 변경
Docs - 문서 업데이트
Add - 일반으로 새로운 것 추가
패키지 추가 package
모듈 추가 modules
Content - 기능에 영향을 주지 않는 정적 콘텐츠 변경 정적컨텐츠와 동적컨텐츠
Revert -커밋 혹은 변경사항 취소
Remove - 파일 혹은 기능 제거
1-1. 제목 작성 규칙
50 글자를 넘으면 안된다.
대문자로 작성해야 하고 마침표를 찍지 않는다.
과거 시제로 적지 않는다
2. 본문
선택 사항이긴 하나 제목만으로는 commit의 내용을 다 담을 수 없기에 적는 것이 더 좋으나 최대 72 자를 넘지 않는 것이 좋다.
3. 꼬릿말
선택 사항이며 이 부분은 가이드마다 다른 듯하다. 이슈 번호, 커밋 번호, 작업단위별 번호 등을를 작성하기도 하고 팀원들에게 보내는 짧은 커밋 메시지를 보내기도 한다.
두 가지의 참고 문서를 보다보면 약간 씩의 차이가 있음을 알 수 있다. 회사마다 커밋 규칙이 다를 수 있으니 가볍게 읽어보며 "나는 이런 방식, 이런 타입을 사용해야지" 정도로만 정리하였다.
