오늘은 깃 커밋 메세지 컨벤션을 정리해보려고 한다.
별다른 컨벤션을 정하지 않고 팀 프로젝트를 진행했더니 관련 커밋을 찾을 때 굉장히 어려웠다.
그리고 내가 작성한 커밋도 스타일이 통일되어 있지 않아서, 다른 사람들이 볼 때 불편했을 것 같아 반성했다.
앞으로 만나게 될 팀(혹은 프로젝트)마다 사용될 컨벤션은 다르겠지만, 우선 내 스타일을 통일해 둘 필요는 있다고 생각하여 글을 작성한다 :)
최초로 본 글은 더블에스 님의 devlog의 글이었고,
참조하신 Udacity Git Commit Message Style Guide 글을 나도 참조하여 글을 작성하였다.
1. Message Structure
커밋 메세지는 빈 줄로 구분되는 세 부분으로 구성된다.
subject, body(선택), footer(선택)
type: Subject
body
footer2. Types
커밋 메세지 타입의 예시들이다.
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# design : CSS 등 사용자 UI 디자인 변경
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# refactor: 리팩토링
# comment : 필요한 주석 추가 및 변경
# docs : 문서 (문서 추가, 수정, 삭제)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트, 패키지 매니저 설정 수정 등)
# rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
# remove : 파일을 삭제하는 작업만 수행한 경우
# !HOTFIX : 급하게 치명적인 버그를 고쳐야하는 경우
# !BREAKING CHANGE : CHANGE 커다란 API 변경의 경우3. Subject
1️⃣ 제목은 영어 50자 이하 (한글은 25자 이하)
2️⃣ 대문자로 시작
3️⃣ 제목 끝에 마침표(.) 금지
4️⃣ `명령형 어조` 사용하기 (적용 시, 이 커밋은 <커밋 메시지> 합니다)
예) "changed" or "changes" => `Change`
예) "fixed" => `Fix` fixed와 fix를 혼용해서 자주 썼는데,
정확한 의미 전달을 위해선 무엇을 했냐가 아닌 무엇을 '한다'가 좋다고 한다.
4. Body, Footer
Body와 Footer는 필요 시에만 사용하면 된다.
Body : 커밋에 대한 설명이 필요할 때 사용
1️⃣ '어떻게' 보다 '무엇을'&'왜'를 설명한다.
2️⃣ 제목과 본문을 한 줄 띄워 분리하기
3️⃣ 본문은 영어 72자 마다 개행 (한글은 36자 마다)
4️⃣ 본문에 여러줄의 메시지를 작성할 땐 “-”로 구분Footer : Issue Tracker ID를 참조하는 데 사용
1️⃣ 꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.
2️⃣ 꼬리말은 “유형: #이슈 번호” 형식으로 사용합니다.
3️⃣ 여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.
4️⃣ 이슈 트래커 유형은 다음 중 하나를 사용합니다.
- Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
- Resolves: 이슈를 해결했을 때 사용
- Ref: 참고할 이슈가 있을 때 사용
- Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
- ex) Fixes: #45 Related to: #34, #23
5. 작성 템플릿
<타입>: <제목>
본문
꼬리말
Issues: #이슈번호
Resolves: #이슈번호
See also: #이슈번호마치며
이전엔 주로 feature/feat, fixed, styled/designed, refactoring 으로 커밋메세지 제목의 시작을 달곤 했다.
여기저기서 들어본 것들을 다 적용하다보니 의미를 적절히 구분하지 못하고 쓴 커밋 제목이 많다.
한동안 커밋메세지를 작성할 때, 이 글을 계속 참고하여 써야겠다.
👉🏻 p.p 형태를 버리고 명령형으로 작성
👉🏻 type 구분 명확하게 하기
출처
Udacity Git Commit Message Style Guide
Git - 커밋 메시지 컨벤션
Git/Github 사용법 간단 정리
