[git] 깃 커밋 메세지 컨벤션

커밋 메시지의 7가지 규칙

1. 제목과 본문을 빈 행으로 구분한다.
2. 제목은 50글자 이내로 제한한다.
3. 제목의 첫 글자는 대문자로 작성한다.
4. 제목 끝에는 마침표를 넣지 않는다.
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
6. 본문의 각 행은 72글자 내로 제한한다.
7. 어떻게 보다는 무엇과 왜를 설명한다

커밋 메시지 구조

// Header, Body, Footer는 빈 행으로 구분한다.
타입(스코프): 주제(제목) // Header(헤더)

본문 // Body(바디)

바닥글 // Footer

Header는 필수이며 스코프는 생략 가능하다.

타입은 해당 커밋의 성격을 나타내며 아래 중 하나여야 한다.

 

1. 제목(Subject)

제목은 코드의 변경 사항에 대해 짧은 요약을 나타냅니다. 아래와 같은 규칙을 지켜주도록 합시다.

영어로 제목을 작성하는 경우

만일 영어로 작성한다면 다음의 규칙을 따릅니다.

 

 

제목은 50자를 넘기지 않고, 대문자로 작성하며 마침표를 붙이지 않습니다.

제목은 과거형을 사용하지 않고, 명령조로 시작합니다.

• ex) 제목을 Fixed 가 아닌, Fix 로 작성합시다. ( 커밋메시지를 예를들어 Fix : "Modify album buy bug" 로 작성하기 )

한글로 제목을 작성하는 경우

"고침", "추가", "변경" 등의 명령조 로 시작합니다. ex) Feat: "추가 get data api 함수"

 

---

2. 본문(Body)

본문은 아래와 같은 규칙에 따라 작성해주도록 합시다.

선택사항입니다. (본문은 꼭 작성 안해도 됨)

 

• 1. 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성해주면 됩니다.
  2. 본문 내용은 어떻게 변경했는지 보다, 무엇을 변경했는지 또는 왜 변경했는지 를 설명하도록 합시다.
  3. 제목과 구분되기 위해 공백 한 줄을 띄워서 작성해줍시다.

---

3. footer (꼬리말)

footer 도 마찬가지로 아래 규칙들에 따라 작성해주도록 합시다.

선택사항 (꼭 작성할 필요x)

• 1. issue tracker id 를 작성할 때 사용합니다.
  2. 형식 : 꼬리말은 "유형: #이슈 번호" 형식으로 사용합니다.

issue tracker 유형은 다음 중 하나를 사용합니다.

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

ex) Fixes: #45 Related to: #34, #23

---

 

타입 이름내용

feat	새로운 기능에 대한 커밋
fix	버그 수정에 대한 커밋
build	빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋
chore	그 외 자잘한 수정에 대한 커밋
ci	ci 관련 설정 수정에 대한 커밋
docs	문서 수정에 대한 커밋
style	코드 스타일 혹은 포맷 등에 관한 커밋
refactor	코드 리팩토링에 대한 커밋
test	테스트 코드 수정에 대한 커밋
perf	성능 개선에 대한 커밋

 

Body는 Header에서 표현할 수 없는 상세한 내용을 적는다.

Header에서 충분히 표현할 수 있다면 생략 가능하다.

Footer는 바닥글로 어떤 이슈에서 왔는지 같은 참조 정보들을 추가하는 용도로 사용한다.

예를 들어 특정 이슈를 참조하려면 Issues #1234 와 같이 작성하면 된다.

Footer는 생략 가능하다.

작성 예시

git commit -m "fix: Safari에서 모달을 띄웠을 때 스크롤 이슈 수정

모바일 사파리에서 Carousel 모달을 띄웠을 때,
모달 밖의 상하 스크롤이 움직이는 이슈 수정.

resolves: #1137

커밋 메시지 Emoji

---

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://haon.blog/haon/github/convention/