Commit Convention은 쉽게말해 commit 할 때 commit message에 대한 약속 같은 것이다.
마구잡이로 적어놓은 커밋 메세지가 누적 될 수록 가독성은 떨어지게 된다.
특히 함께하는 프로젝트 일수록 안된 Commit은 큰 혼란을 야기한다.
협업하는 사람들 간의 커밋 메세지 스타일을 정해두면 자신의 이전 코드를 살펴보는데 도움도 되고, 팀원 간 코드리뷰도 용이하다.
Git Commit Message 기본적인 작성법을 알아보자
현재 일반적으로 사용되고 있는 Git 커밋 메세지 기본은 다음과 같다
type(옵션): [#issueNumber - ]Subject // -> 제목
(한 줄을 띄워 분리합니다.)
body(옵션) // -> 본문
(한 줄을 띄워 분리합니다.)
footer(옵션) // -> 꼬리말
Type
타입은 태그와 제목으로 구성되고, 태그는 영어로 쓰되 첫문자는 대문자로 한다.
"태그: 제목"의 형태이며, :뒤에만 space가 있음에 유의한다.
태그 이름 설명
Feat: 새로운 기능을 추가할 경우
Fix: 버그를 고친 경우
Design: CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE: 커다란 API 변경의 경우
!HOTFIX: 급하게 치명적인 버그를 고쳐야하는 경우
Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor: 프로덕션 코드 리팩토링
Comment: 필요한 주석 추가 및 변경
Docs: 문서를 수정한 경우
Test: 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore: 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove: 파일을 삭제하는 작업만 수행한 경우
태그는 다음과 같은 종류로 구분 할 수 있다. 태그 뒤에는 ":"를 붙여 제목과 구별이 가능하도록 한다.
1. 기능
2. 개선
3. 그 외
Feat, Fix, Design, !BREAKING CHANGE 같은 태그가 기능태그의 종류임
Feat: 새로운 기능을 추가할 경우
Fix: 버그를 고친 경우
Design: CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE: 커다란 API 변경의 경우 (ex API의 arguments, return 값의 변경, DB 테이블 변경, 급하게 치명적인 버그를 고쳐야 하는 경우)
추가적인 문맥 정보제공을 위한 목적으로 괄호안에 작성도 가능하다
ex)
"Feat(navigation):"
"Fix(database):"
Style, Refactor, Comment 태그가 개선태그의 종류이다
Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor: 프로덕션 코드 리팩토링, 새로운 기능이나 버그 수정없이 현재 구현을 개선한 경우
Comment: 필요한 주석 추가 및 변경
Style의 경우 오타수정, 탭 사이즈 변경, 변수명 변경 등에 해당하고, Refactor의 경우 코드를 리팩토링 하는 경우에 적용가능
Docs, Test, Chore, Rename, Remove 태구가 그 외의 종류임
Docs: 문서를 수정한 경우
Test: 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 없음)
Chore: 빌드 태스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)
Rename: 파일 혹은 폴더명을 수정하는 경우
Remove: 사용하지 않는 파일 혹은 폴더를 삭제하는 경우
Docs의 경우 README.md 수정 등에 해당하고, Test는 test폴더 내부의 변경이 일어난 경우에만 해당한다.
Chore의 경우 package.json의 변경이나 dotenv요소변경 등, 모듈의 변경에 해당됨
제목은 코드 변경에 대한 짧은 요약을 나타냄, 제목은 다음과 같은 규직은 지킨다.
- 제목의 처음은 동사 원형으로 시작합니다.
- 총 글자 수는 50자 이내로 작성합니다.
- 마지막에 특수문자는 삽입하지 않습니다. 예) 마침표(.), 느낌표(!), 물음표(?)
- 제목은 개조식 구문으로 작성합니다.
영어로 작성 시 다음 규칙을 따음
- 첫 글자는 대문자 작성
- "Fix", "Add", "Change"의 명령어로 시작
한글제목 작성시 다음규칙을 따른다
- "고침", "추가", "변경"의 명령어로 시작
ex)
Feat: "추가 get data api 함수"
본문은 다음규칙을 따른다
- 본문은 한 줄 당 72자 내로 작성합니다.
- 본문 내용은 양에 구애받지 않고 최대한 상세히 작성합니다.
- 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명합니다.
꼬리말은 다음과 같은 규칙을 따름
- 꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.
- 꼬리말은 "유형: #이슈 번호" 형식으로 사용합니다.
- 여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.
- 이슈 트래커 유형은 다음 중 하나를 사용합니다.
- Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
- Resolves: 이슈를 해결했을 때 사용
- Ref: 참고할 이슈가 있을 때 사용
- Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
ex) Fixes: #45 Related to: #34, #23
Feat: "추가 로그인 함수"
로그인 API 개발
Resolves: #123
Ref: #456
Related to: #48, #45
Emoji - Description
🎨 - 코드의 형식 / 구조를 개선 할 때
📰 - 새 파일을 만들 때
📝 - 사소한 코드 또는 언어를 변경할 때
🐎 - 성능을 향상시킬 때
📚 - 문서를 쓸 때
🐛 - 버그 reporting할 때, @FIXME 주석 태그 삽입
🚑 - 버그를 고칠 때
🐧 - 리눅스에서 무언가를 고칠 때
🍎 - Mac OS에서 무언가를 고칠 때
🏁 - Windows에서 무언가를 고칠 때
🔥 - 코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜 - 파일 구조를 변경할 때 . 🎨과 함께 사용
🔨 - 코드를 리팩토링 할 때
☔️ - 테스트를 추가 할 때
🔬 - 코드 범위를 추가 할 때
💚 - CI 빌드를 고칠 때
🔒 - 보안을 다룰 때
⬆️ - 종속성을 업그레이드 할 때
⬇️ - 종속성을 다운 그레이드 할 때
⏩ - 이전 버전 / 지점에서 기능을 전달할 때
⏪ - 최신 버전 / 지점에서 기능을 백 포트 할 때
👕 - linter / strict / deprecation 경고를 제거 할 때
💄 - UI / style 개선시
♿️ - 접근성을 향상시킬 때
🚧 - WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎 - New Release
🔖 - 버전 태그
🎉 - Initial Commit
🔈 - 로깅을 추가 할 때
🔇 - 로깅을 줄일 때
✨ - 새로운 기능을 소개 할 때
⚡️ - 도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡 - 새로운 아이디어, @IDEA주석 태그
🚀 - 배포 / 개발 작업 과 관련된 모든 것
🐘 - PostgreSQL 데이터베이스 별 (마이그레이션, 스크립트, 확장 등)
🐬 - MySQL 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🍃 - MongoDB 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🏦 - 일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)
🐳 - 도커 구성
🤝 - 파일을 병합 할 때