Git 커밋 메시지를 잘 쓰려고 노력해야 하는 이유
- 더 좋은 커밋 로그 가독성
- 더 나은 협업과 리뷰 프로세스
- 더 쉬운 코드 유지보수
그 외에도 CHANGELOG들을 자동으로 생성하고, 빌드와 배포 프로세스를 트리거하는 등의 역할을 할 수도 있다.
좋은 커밋 메시지를 작성하는 방법은 여러 가지가 있겠지만, Angular Commit Guidelines에 기반을 둔 Conventional Commits 1.0.0과 가장 유명한 Udacity의 Git 커밋 메시지 컨벤션을 정리해 보고 추가로 메모해두고 싶은 내용들을 작성해 보았다.
Conventional Commits 1.0.0
Conventional Commits
A specification for adding human and machine readable meaning to commit messages
www.conventionalcommits.org
<type>[optional scope]: <description>
[optional body]
[optional footer]
예제로 확인해 보자!
Commit message with description and breaking change in body
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
Commit message with optional ! to draw attention to breaking change
chore!: drop Node 6 from testing matrix
BREAKING CHANGE: dropping Node 6 which hits end of life in April
Commit message with no body
docs: correct spelling of CHANGELOG
Commit message with scope
feat(lang): add polish language
Commit message for a fix using an (optional) issue number.
fix: correct minor typos in code
see the issue for details on the typos fixed
closes issue #12
Udacity Git Commit Message Style Guide
Udacity Nanodegree Style Guide
Introduction This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development. Therefore, in order to reduce the
udacity.github.io
Udacity의 git 커밋 메시지 스타일은 공백 라인으로 구분된 세 가지 명확한 부분으로 이루어져 있다.
제목, 본문, 꼬리말 세 가지 파트로 나뉜다.
type: Subject
body
footertype
어떤 의도로 커밋했는지 type에 명시
| 타입 종류 | 설명 |
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 들여쓰기, 누락된 세미콜론 등의 변경; 코드 변경 없음 |
| refactor | 코드 리팩토링 |
| test | 테스트 추가 또는 기존 테스트 수정; 프로덕션 코드 변경 없음 |
| chore | 빌드 작업, 패키지 매니저 구성 등 업데이트; 프로덕션 코드 변경 없음 |
Udacity 문서에는 없었지만, 그 외 괜찮았던 타입 종류들
| 타입 종류 | 설명 |
| design | CSS 등 사용자 UI 디자인 변경 |
| comment | 필요한 주석 추가 및 변경 |
| rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만 수행한 경우 |
| remove | 파일을 삭제하는 작업만 수행한 경우 |
subject
- 최대 50자가 넘지 않도록 하고 마침표는 찍지 않기
- 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기
- 과거 시제를 사용하지 않고 명령어로 작성
- Fixed -> Fix
- Added -> Add
- Changed -> Change
- 한글로 작성한다면 "인증 메서드 수정"과 같이 작성하면 된다.
body
- 선택사항
- 부연설명이 필요하거나 커밋의 이유(무엇을 왜 변경했는지)를 설명할 경우 작성
- 한 줄 당 72자 이내로 작성
footer
- 선택사항
- 이슈 트래커 ID를 참조할 때 사용
fixes, resolves, closes
이 키워드는 특정 이슈를 해결할 때 사용
GitHub에서는 이 키워들을 사용하면 해당 커밋이 푸시될 때 자동으로 이슈를 닫는다.
- Fixes: 이슈가 해결됨
- Resolves: 이슈가 해결됨
- Closes: 이슈가 해결됨
Fixes #123
Resolves #123
Closes #123Linking a pull request to an issue - GitHub Docs
You can link a pull request or branch to an issue to show that a fix is in progress and to automatically close the issue when the pull request or branch is merged.
docs.github.com
Ref, Related to
이 키워드는 특정 이슈에 대한 참조나 관련성을 나타낼 때 사용
이슈가 해결되지는 않았지만, 관련된 작업임을 명시할 수 있다.
이슈를 닫지는 않는다.
- Ref: 특정 이슈를 참조
- Related to: 특정 이슈와 관련이 있음을 나타냄
Ref #456
Related to #456
See, See also
이 키워드는 주로 문서나 다른 커밋, 이슈 등을 참조할 때 사용
See https://example.com/code-reviews/456
See also #789
Co-authored-by
이 키워드는 여러 사람이 함께 작업한 커밋임을 나타낼 때 사용
공동 작업자의 이메일과 함께 작성
Co-authored-by Jane Doe <jane.doe@example.com>
Co-authored-by John Smith <john.smith@example.com>
