아직 대학생따리지만 동아리에서 프로젝트를 할 때 커밋 내용을 어떻게 써야할지 고민이 많았다.
개인 프로젝트는 혼자 막 갈겨 써도 이해할 수 있지만
협업하는 상황이라면 글을 쓸 때도 공통의 규칙이 있어야 상황파악이나 이후 업무 분배에 있어서도 더 수월할 것이다.
구글에다가 Git convention이라고 치면 정말 많은 자료가 나오는데
이제 커밋할 때마다 일일이 컨벤션 확인하고 쓰기 싫어서 아예 각 잡고 한 번 정리해보려고 한다.
1. Commit Message Structure
기본적인 커밋 메시지 구조는 이렇다. (각 파트는 빈줄로 구분한다.)
제목 (Type: Subject)
(한줄 띄어 분리)
본문 (Body)
(한줄 띄어 분리)
꼬리말 (Footer)
2. Commit Type
태그: 제목
:(space)제목 으로 :뒤에만 space를 넣는다.
위와 같은 형식으로 작성하게 되는데 사용 가능한 태그로는 아래와 같은 태그들이 있다.
| Tag Name | Description |
| Feat | 새로운 기능을 추가 |
| Fix | 버그 수정 |
| Design | CSS 등 사용자 UI 디자인 변경 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야 하는 경우 |
| Style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서 수정 |
| Test | 테스트 코드, 리팩토링 테스트 코드 추가, Production Code 변경 없음 |
| Chore | 빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음 |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |
3. Subject
- 제목은 50글자 이내로 작성한다.
- 첫글자는 대문자로 작성한다.
- 마침표 및 특수기호는 사용하지 않는다.
- 영문으로 작성하는 경우 동사(원형)을 가장 앞에 명령어로 작성한다.
- 과거시제는 사용하지 않는다.
- 간결하고 요점적으로 즉, 개조식 구문으로 작성한다.
ex)
Fixed-> Fix
Added -> Add
Modified -> Modify
4. Body
- 72자 이내로 작성한다.
- 최대한 상세히 작성한다. (코드 변경의 이유를 명확히 작성할수록 좋다)
- 어떻게 변경했는지보다 무엇을, 왜 변경했는지 작성한다.
5. Footer
- 선택사항
- issue tracker ID 명시하고 싶은 경우 작성한다.
- 유형 : #이슈 번호 형식으로 작성한다.
- 여러개의 이슈번호는 콤마(,)로 구분한다.
- 이슈 트래커 유형은 다음 중 하나를 사용한다.
Fixes : 이슈 수정중 (아직 해결되지 않은 경우)
Resolves : 이슈를 해결했을 때 사용
Ref : 참고할 이슈가 있을 때 사용
Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
ex)
Fixes : #45 Related to : #34, #23
복붙 안하고 일일이 하나씩 타이핑하니깐 이제 좀 머릿속에 들어오는 느낌이다.
여러글을 보던 와중에 이건 그저 하나의 가이드라인 중 하나일 뿐 회사마다 팀마다 스타일은 다를 수도 있다고 한다.
그래도 일단 이제 컨벤션 즉, 전통이니깐 특별한 가이드라인이 따로 없다면 이 컨벤션을 익혀두도록 하자.