협업 프로젝트를 진행하다 보면 다양한 스타일의 커밋 메시지로 인해 커뮤니케이션에 어려움을 겪는 경우가 많습니다. 특히 팀원이 많아질수록 코드뿐만 아니라 커뮤니케이션 방식에도 일관성이 필요합니다.
이 글에서는 협업을 효율적으로 하기 위해 현재 제가 진행 중인 프로젝트 팀에서 사용 중인 Commit Convention을 정리해 보았습니다.
Commit Convention
저희 팀의 커밋 컨벤션은 Conventional Commits를 참고하여 결정했습니다.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Convetional Commits는 위와 같은 커멧 메시지 구조를 정의하고 있습니다.
저희 팀은 커밋 헤더만을 채택하고, optional한 body와 footer는 사용하지 않기로 하였습니다.
🛠️ 커밋 작성 원칙
- 한 커밋에는 한 가지 의미만 담는다.
- 기능이 작게 쪼개지지 않았다면, 더 세분화할 수 있는 방법이 없는지 고민해 본다.
- 커밋 헤더만 보더라도 무엇이 변경되었는지 파악할 수 있도록 작성한다.
❌ body와 footer를 사용하지 않는 이유
저희 팀은 커밋의 바디나 푸터보다는 PR을 통해 기능 설명을 자세히 남기기로 합의했습니다.
그 이유는 다음과 같습니다:
- 커밋 헤더만으로도 충분히 의미를 전달할 수 있는 구조로 작성하면, 커밋 히스토리를 읽기 쉬움
- 바디와 푸터를 무리하게 작성하기보다, PR에서 문맥과 의도를 충분히 설명하는 것이 효율적
- 커밋을 작게 쪼개어 기록함으로써 변경 이력을 추적하기 쉬워짐
✅ 커밋 타입 예시
| Feat | 새로운 기능 추가 |
| Fix | 버그 수정 |
| Docs | 문서 수정 |
| Style | 코드 포맷팅 (세미콜론 등) |
| Refactor | 코드 리팩토링 (기능 변화 없음) |
| Test | 테스트 코드 추가 또는 수정 |
| chore | 기타 변경사항 (빌드, 설정 파일 등) |
✅ 커밋 메시지 예시
위처럼 커밋 컨벤션을 적용하여, 어떤 커밋이 어떤 의도를 가지고 작성되었는지 명확해졌고. Git 로그를 통해 변경사항을 구조적으로 파악하는 것이 더 수월해졌습니다.
