Git 커밋 메시지 컨벤션(이하 커밋 컨벤션)은 일관된 형식의 커밋 메시지를 작성하기 위한 규칙이다.
프로젝트 상황에 맞게 수정할 수 있다.
한 프로젝트에 여러 개발자가 서로 다른 방식의 커밋 메시지를 작성한다면 여러 문제를 겪게 된다. 하지만 커밋 컨벤션을 도입함으로 아래의 이득을 얻을 수 있다.
가독성
가독성 향상으로 소스 변경 이력을 쉽게 파악할 수 있다.
커뮤니케이션
버그 수정 과정에서 타 개발자와의 불필요한 의사소통을 줄일 수 있다.
변경 이력 추적
문제 발생 시 변경 이력을 효율적으로 추적하여 대처할 수 있고 이로인해 프로젝트 안정성을 향상시킬 수 있다.
문서화 기능
소스 변경 내역을 제공하는 문서 역할을 하여 효율적인 소스 코드 분석이 가능하다.
자동화
특정 태그 및 내용을 기반으로 버전 릴리즈, 머지, 통계, 분석 등 다양한 작업을 자동화할 수 있다.
다양한 커밋 컨벤션이 존재하지만 이 문서는 가장 대중적인 커밋 컨벤션인 Udacity Git Commit Message Style Guide🔗 를 기반으로 한다.
(이모티콘을 사용한 gitmoji 컨벤션도 존재한다.)
메시지 구조는 제목, 본문, 꼬리말로 나뉘고 한 줄을 띄워 서로 구분한다.
본문, 꼬리말은 선택사항이다.
type: Subject -> 제 목
(한칸 띄우기)
body(option) -> 본 문
(한칸 띄우기)
footer(option) -> 꼬리말
아래는 각 부분을 어떻게 작성하는지 설명한다.
태그를 통해 어떤 유형의 변경 사항이 도입되었는지 식별한다.
만약 사용할 태그가 2개 이상이라면 커밋을 더 작게 나눌 필요가 있다.
:
)을 통해 구분한다. (콜론 뒤 띄어쓰기)태그 이름 | 설명 |
---|---|
Feat | 새로운 기능 추가 |
Fix | 버그 수정 |
Docs | 문서 수정 |
Style | 코드 의미에 영향을 주지 않는 변경 (예: 코드 포맷팅, 세미콜론 누락 등) |
Refactor | 프로덕션 코드 리펙토링 |
Test | 테스트 코드, 리펙토링 테스트 코드 추가 |
Chore | 빌드 업무 수정, 패키지 매니저 수정 |
Design | UI 디자인 변경 |
Rename | 파일 수정 및 이동 |
Remove | 파일 삭제 |
영어의 경우
이슈 트래커 ID를 작성한다.
유형: #이슈 번호
형식이다.
이슈가 여러개면 쉼표로 구분한다.
이슈 트래커 유형은 아래와 같다.
유형 | 내용 |
---|---|
Fixes | 이슈 수정중 |
Resolves | 이슈 해결 |
Ref | 참고할 이슈 |
Related to | 해결되지 않은 관련된 이슈 |
예) Fixes: #5 Related to: #2, #3
Feat: 로그인 함수 추가
로그인 API 개발
Resolves: #123
Ref: #456
Related to: #48, #45
우선 커밋 컨벤션 관련 글을 쓰게된 이유는 현회사에서 커밋 컨벤션이 존재하지 않아 대표님과 이야기하여 도입하기로 하였다. 지금까지 제목만 사용했는데 조사하면서 본문, 꼬리말이 있는 것도 처음 알았다. 또한 단순 가독성 뿐 아니라 여러 장점이 많아서 신기하기도 했다.
아직은 완벽히 활용하지는 못하지만 차츰 완벽에 가깝게 사용할 수 있으면 좋겠다.
https://github.com/slashsbin/styleguide-git-commit-message#tools
https://overcome-the-limits.tistory.com/entry/협업-협업을-위한-기본적인-git-커밋컨벤션-설정하기#타입
https://www.conventionalcommits.org/ko/v1.0.0/
https://insight.infograb.net/blog/2023/04/21/why-commit-convention-is-important/