Git Commit Convention

💡 Commit Message

 

Type(Optional) : [# Issue-Number -] Subject   -> 제목
줄바꿈
Body(Optional)  -> 본문
줄바꿈
Footer(Optional) -> 꼬리말

 

• Type : 어떤 의도의 커밋인지 Type에 명시
• Subject : 최대 50글자, 마침표 X, 영문 표기 시 동사(원형)를 가장 앞에두고 첫글자는 대문자 표기
• Body : 긴 주석이 필요할 경우 작성, 어떻게가 아닌 무엇을 & 왜 했는지 작성, 최대 75글자
• Footer : Issue Tracker ID 명시 (옵션)

---

💡 제목 & 태그 작성법

 

타입 : 태그와 제목으로 구성, 태그는 영어로 쓰고 첫글자는 대문자 표기
"태그: 제목" 의 형태이며 : 뒤에만 공백1칸 있음을 유의

 

제목 작성

• 제목의 처음은 동사원형으로 시작
• 최대 50글자
• 마지막에는 특수문자 X (마침표,느낌표,물음표 등)
• 제목은 개조식 구문으로 작성
• 한글제목 작성 시 규칙
  • "고침", "추가", "변경"의 명령어로 시작
• 영어제목 작성 시 규칙
  • 첫글자는 대문자
  • "Fix", "Add", "Change"의 명령어로 시작
• 예시
  • Feat: "추가 get data api 함수"

 

태그 이름	설명
Feat	새로운 기능을 추가할 경우
Fix	버그를 고친 경우
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore	빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우

 

 

태그의 종류 - 태그의 뒤에 : 를 붙여 제목과 구별

• 기능
  • Feat - 새로운 기능 추가
  • Fix - 버그 fix
  • Design - UI 디자인 변경
  • !BREAKING CHANGE - 큰 규모의 API 변경의 경우
  • ※ 추가 문맥정보 제공을 위한 () 사용 가능 ex) "Fix(DB):"
• 개선
  • Style - 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없을 때
  • Refactor - 프로덕션 코드 리팩터링, 새로운 기능 & 버그수정 없이 현재 구현을 개선한 경우
  • Comment - 주석 추가 & 변경
• 그 외
  • Docs - 문서 수정한 경우
  • Test - 테스트 추가 & 리팩터링 (프로덕션 코드 변경 X)
  • Chore - 빌드 태스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 X)
  • Rename - 파일 & 디렉토리 명을 수정하는 경우
  • Remove - 미사용 파일 & 디렉토리를 삭제하는 경우

---

💡 본문 & 꼬리말 작성법

본문 규칙

본문은 한 줄 당 최대 72자
양에 신경쓰지 않고 최대한 구체적으로 작성
어떻게 보다 무엇을 & 왜 에 집중

 

꼬리말 규칙

꼬리말의 적용은 Optional 이다
"유형: #이슈 번호" 형식으로 사용
다수의 이슈 번호 작성 시 쉼표로 구분
사용 이슈 트래커 유형
- Fixes : 이슈 수정 중 (미해결)
- Resolves : 이슈 해결 시 사용
- Ref : 참고할 이슈가 있을때 사용
- Related to : 해당 커밋에 관련된 이슈 번호 (미해결)
※ ex) Fixes: #31 Related to: #25, #8

 

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