커밋메시지 컨벤션이란? : Conventional Commits 소개

 
커밋메시지를 작성할 때, 일관된 규칙을 따르는 정해놓고 따르도록 하는 것을 '커밋메시지 컨벤션'이라고 한다.
커밋메시지 컨벤션 중에서도 많이 사용되는 'Conventional Commits' 을 소개하려고 한다. 
Conventional Commits 사이트에 방문하면, 구조와 구성 요소, 사용 사례가 자세히 나와있다.
 

Conventional Commits 사용 목적

• CHANGELOG를 자동으로 생성하기 위해서
• (포함된 커밋의 타입에 기반하여) 유의적 버전을 자동으로 변경하기 위해서
• 팀 동료, 타인, 그리고 기타 이해당사자에게 변화의 본질을 전달하기 위해서
• 빌드와 배포 프로세스를 수행하기 위해서
• 더 구조화된 커밋 히스토리를 보여줘서 사람들이 프로젝트에 기여하기 더 쉽도록 하기 위해서

 

구조

<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]

구성요소(<타입>, 본문, 꼬리말)

build: 시스템 또는 외부 종속성에 영향을 미치는 변경사항 (npm, gulp, yarn 레벨)
ci: ci구성파일 및 스크립트 변경
chore: 빌드 설정 변경, 코드 포맷팅, 문서 업데이트 등의 코드 변경이 아닌 작업
docs: 문서 관련 업데이트
feat: 새로운 기능
fix: 버그 수정
perf: 성능 개선 관련 업데이트
refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경, 리팩토링
style: 코드 의미에 영향을 주지 않는 변경사항 ( white space, formatting, colons )
test: 누락된 테스트 추가 또는 기존 테스트 수정 (테스트 코드 관련 업데이트)
revert: 작업 되돌리기

-> 개발 과정 중에서는  feat, fix, refactor, style 을 많이 사용하는 것 같다. 
 

스펙에 맞는 타입을 사용하고 있지만 올바른 타입이 아닌 경우, 예를 들어, feat 대신 fix

실수를 병합 또는 리베이스하기 전에, git rebase -i를 사용하여 커밋 히스토리를 편집할 것을 권장합니다. 릴리즈 후에는 사용하는 툴과 프로세스에 따라 정리하는 방법이 다를 수 있습니다.
-> 커밋 메시지를 잘못 남겨서 git rebase 를 통해 히스토리 편집한 적이 몇 번 있었는데, 공식 문서에서도 이를 권장하고 있었다.
 
 출처

Conventional Commits

 

효율적인 commit message 작성을 위한 conventional commits