혼자서 프로젝트를 진행하며 버전 관리 용도로만 깃을 사용한다면 커밋 메시지를 아무렇게나 적어도 큰 문제될 일은 없습니다. 물론 본인도 알아볼 수 있다는 메시지를 남긴다는 가정 하에서요.
하지만 협업을 진행한다면 그때부터는 이야기가 달라지게 됩니다. 원활한 협업을 위해 모두가 이해할 수 있는 커밋 메시지 규칙들을 세우고 규칙을 따라서 커밋 메시지를 작성해야합니다.
그래서 오늘은 커밋 메시지를 작성하는 대표적인 규칙들을 소개해볼까 합니다.
커밋 메시지 작성의 권장 사항 ✏️
구글에 git commit message convention라고 검색했을 때 가장 많이 강조되는 권장 사항들을 다섯 가지 정리했습니다.
- 제목은 50자 이내로 간결하게 작성한다
- 제목 끝에 마침표
.를 붙이지 않는다 - 영문 기준으로 모든 문장의 첫 글자를 대문자로 작성한다
- 내용이 길 경우 제목과 한 줄을 띄우고 본문을 작성한다
- 본문은 한 줄에 72자를 넘지 않도록 한다
이 외에도 명령형 문장을 사용하라, 본문에서는
What-Why를 서술하라 등의 사항들도 존재합니다.
어디까지나 권장 사항이기에 이 사항들을 기본 베이스로 삼아 팀의 성향에 맞게 조금씩 조절하여 메시지 작성 규칙을 세우면 됩니다.
커밋 메시지 구조 🔧
작성 규칙 다음으로 중요한 것이 정형화된 커밋 메시지(제목)입니다. 50자 내의 짧은 문장에 변경 사항을 담아내면서도 모두가 이해할 수 있도록 만들기 위해 정형화된 제목 구조를 가지게 됩니다.
대표적으로 사용되는 구조는 Conventional Commits입니다.
Conventional Commits
일반적으로 사용되는 구조이며 정리하자면 다음과 같습니다.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]여기서 type은 어떤 변경사항이 생겼는지 한 단어로 명시하는 것이며 다음과 같은 type들이 주로 사용됩니다.
| type | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | README.md 등의 문서 작업 |
| style | 코드 포맷팅 |
| refactor | 기능 변경 없는 구조 개선(= 리팩토링) |
| test | 테스트 추가 or 수정 |
| chore | 빌드, 패키지 매니저, 설정 등 작업 |
| perf | 성능 향상 관련 작업 |
| build | 빌드, 의존성 관련 작업 |
| ci | CI 구성 관련 작업 |
마찬가지로 팀 성향에 맞춰서 type은 조금씩 변경하여 사용하도록 합시다. 다만 구조는 반드시 지켜주는 것이 좋습니다.
optional scope는 변경된 도메인 등을 의미합니다.
예를 들어 로그인 관련 기능이 추가되면feat(auth): 로그인 기능 추가와 같은 식으로 작성합니다. 이는 optional이기 때문에 필수로 넣어야하는 내용도 아닙니다.
이모지 사용하기 😊
요즘 꽤 자주 보이는 방식인데요. 변경 type에 어울리는 이모지를 제목 맨 앞에 접미사로 붙여서 변경 사항을 빠르게 파악할 수 있는 방식입니다.
예를들어 feat는 ✨, fix는 🔧, docs는 📜처럼 팀에서 어떤 type에 어떤 이모지를 쓸지 지정하고 커밋 메시지를 간결하게 작성하는 방식입니다.
✨ feat: 로그인 기능 추가더 간단한 패턴
이 방식도 종종 보이는 방식인데요. 대괄호를 이용해서 변경 사항을 표기합니다.
[ADD] 로그인 API 추가이렇게 Git 커밋 메시지를 작성하는 방법에 대해서 알아보았습니다.
제가 알려드린 것은 어디까지나 기본 베이스이기에 위 사항들을 그대로 채택해도 괜찮고 팀과 협의해서 더 나은 개선 사항이 있다면 팀의 성향에 맞게 변형을 해서 사용하는 것도 좋습니다.
