[Git/Github] Commit Convention

Convention이란?

번역하자면 협약, 관례라는 뜻이다.

쉽게 말하자면 개발자들간 약속이란 뜻으로 Code Convention은 코드에 관련한 약속이라는 뜻.

naming convention을 대표적으로 들자면, 카멜 케이스(camelCase), 스네이크 케이스(snake_case), 파스칼 케이스(PascalCase) 등이 있다.

 

Git Commit Convention이란?

쉽게 말해 commit message에 대한 약속이다.

(그냥 나 혼자 개발할 때는 안써도 무방..)

그렇다면 왜 사용하는 걸까?? (면접 질문으로 물어볼 정도로)

 

현업 혹은 프로젝트 간 협업을 할 때, 또는 본인이 알아보기 쉽게 등 다양한 이유에서 커밋 컨벤션이 필요하다.

Commit Convention

커밋 메세지에 대한 약속

커밋 메세지 구조는 크게 3가지로 나뉜다.

type: Subject -> 제목  
(한칸 띄우기)  
body(생략 가능) -> 본문  
(한칸 띄우기)  
footer(생략 가능) -> 꼬리말

 

각 커밋 메시지 구조에는 규칙이 존재한다.

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	파일을 삭제하는 작업만 수행한 경우

 

Subject Rule

• 제목은 50글자 이내로 작성한다.
• 첫글자는 대문자로 작성한다.
• 마침표 및 특수기호는 사용하지 않는다.
• 영문으로 작성하는 경우 동사(원형)을 가장 앞에 명령어로 작성한다.
• 과거시제는 사용하지 않는다.
• 간결하고 요점적으로 즉, 개조식 구문으로 작성한다.

body Rule

• 72이내로 작성한다.
• 최대한 상세히 작성한다. (코드 변경의 이유를 명확히 작성할수록 좋다)
• 어떻게 변경했는지보다 무엇을, 왜 변경했는지 작성한다.

Footer Rule

• 선택사항
• issue tracker ID 명시하고 싶은 경우에 작성한다.
• 유형: #이슈 번호 형식으로 작성한다.
• 여러 개의 이슈번호는 쉼표(,)로 구분한다.
• 이슈 트래커 유형은 다음 중 하나를 사용한다.

Issue Tracker	설명
Fixes:	이슈 수정중(아직 해결되지 않은 경우)
Resolves:	이슈를 해결한 경우
Ref:	참조할 이슈가 있을 때 사용
Related to:	해당 커밋에 관련된 이슈 번호(아직 해결되지 않은 경우)

 

ex) Footer에 Fixes: #1 이라고 작성하고 commit을 할 경우, 자동으로 issue #1과 매칭이 된다.
또한, Resolves: #1으로 이슈를 해결했다고 명시하면 그 이슈는 사라진다.

 

Commit Template

# 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping  

# 본문은 아래에 작성  

# 꼬릿말은 아래에 작성: ex) Github issue #23  

# --- COMMIT END ---  
#   <타입> 리스트  
#   feat        : 기능 (새로운 기능)  
#   fix         : 버그 (버그 수정)  
#   refactor    : 리팩토링  
#   design      : CSS 등 사용자 UI 디자인 변경  
#   comment     : 필요한 주석 추가 및 변경  
#   style       : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)  
#   docs        : 문서 수정 (문서 추가, 수정, 삭제, README)  
#   test        : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)  
#   chore       : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)  
#   init        : 초기 생성  
#   rename      : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우  
#   remove      : 파일을 삭제하는 작업만 수행한 경우  
# ------------------  
#   제목 첫 글자를 대문자로  
#   제목은 명령문으로  
#   제목 끝에 마침표(.) 금지  
#   제목과 본문을 한 줄 띄워 분리하기  
#   본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.  
#   본문에 여러줄의 메시지를 작성할 땐 "-"로 구분  
# ------------------  
#   <꼬리말>  
#   필수가 아닌 optioanl  
#   Fixes        :이슈 수정중 (아직 해결되지 않은 경우)  
#   Resolves     : 이슈 해결했을 때 사용  
#   Ref          : 참고할 이슈가 있을 때 사용  
#   Related to   : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)  
#   ex) Fixes: #47 Related to: #32, #21

 

출처 : https://kdjun97.github.io/git-github/commit-convention/

다른 블로그에서 잘 작성한 템플릿이 있길래 빌려왔다.

또한, Git에 템플릿을 적용하는 방법이 추가적으로 있다. 참고하길 바란다.

Commit Message Emoji(gitmoji)

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 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🏦	일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)
🐳	도커 구성
🤝	파일을 병합 할 때

참조

https://kdjun97.github.io/git-github/commit-convention/

https://velog.io/@archivvonjang/Git-Commit-Message-Convention