1. Commit Message Convention이란
- 프로젝트 참여자들이 일관된 형식의 커밋 메시지를 작성하기 위한 규칙
- 현재 여러 개발자들 사이에서 관습적을 통용되는 가이드라인이 있지만, 프로젝트마다 별도의 규칙을 만들어 적용하기도 함
컨벤션을 지켜야 하는 이유
- 가독성 및 커뮤니케이션 효율성 제고
- 변경 이력 추적 및 문제 해결 속도 향상
-> 다른 개발자의 작업 내역이나 변경사항을 쉽게 파악 가능, 코드 리뷰 및 버그 수정 과정에서 불필요한 의사소통 과정을 간소화하여 프로젝트 관리에 들어가는 시간 절약 가능
2. 기본 컨벤션
1. 기본 형식
2. 커밋의 타입
| 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
6. 커밋 예시
예시1
예시2
Feat: 회원 가입 기능 구현
SMS, 이메일 중복확인 API 개발
Resolves: #123
Ref: #456
Related to: #48, #45
7. 이모지 컨벤션 (gitmoji)
🎨 코드의 형식 / 구조를 개선 할 때
📰 새 파일을 만들 때
📝 사소한 코드 또는 언어를 변경할 때
🐎 성능을 향상시킬 때
📚 문서를 쓸 때
🐛 버그 reporting할 때, @FIXME 주석 태그 삽입
🚑 버그를 고칠 때
🐧 리눅스에서 무언가를 고칠 때
🍎 Mac OS에서 무언가를 고칠 때
🏁 Windows에서 무언가를 고칠 때
🔥 코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜 파일 구조를 변경할 때 . 🎨과 함께 사용
🔨 코드를 리팩토링 할 때
☔️ 테스트를 추가 할 때
🔬 코드 범위를 추가 할 때
💚 CI 빌드를 고칠 때
🔒 보안을 다룰 때
⬆️ 종속성을 업그레이드 할 때
⬇️ 종속성을 다운 그레이드 할 때
⏩ 이전 버전 / 지점에서 기능을 전달할 때
⏪ 최신 버전 / 지점에서 기능을 백 포트 할 때
👕 linter / strict / deprecation 경고를 제거 할 때
💄 UI / style 개선시
♿️ 접근성을 향상시킬 때
🚧 WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎 New Release
🔖 버전 태그
🎉 Initial Commit
🔈 로깅을 추가 할 때
🔇 로깅을 줄일 때
✨ 새로운 기능을 소개 할 때
⚡️ 도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡 새로운 아이디어, @IDEA주석 태그
🚀 배포 / 개발 작업 과 관련된 모든 것
🐘 PostgreSQL 데이터베이스 별 (마이그레이션, 스크립트, 확장 등)
🐬 MySQL 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🍃 MongoDB 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🏦 일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)
🐳 도커 구성
🤝 파일을 병합 할 때Git 커밋 메시지 자동화 방안
1. Git Commit 메시지 템플릿 설정
- 템플릿을 사용하면 메시지의 기본 구조를 제공함으로써 일관된 커밋 메시지를 유도할 수 있게 된다.
- 기본 구조가 적힌 템플릿 파일을 생성한 후, git config commit.template 명령어로 해당 템플릿 파일을 config에 등록하면 됨
2. Git Commit 메시지 자동화 툴
- Commitlint, Git hook
참고 사이트
개발