Git commit message 컨벤션 설정

문제 발견

git commit message 작성시 보통 첫줄에 위치한 제목줄에 들어가는 가이드로서,
이전에 내가 사용하던 규칙은 다음과 같았다.

• Add - 레이아웃 / 기능 추가
• Remove - 내용 삭제 (폴더 / 파일 삭제)
• Modify - 수정 (JSON 데이터 포맷 변경 / 버튼 색깔 변경 / 폰트 변경)
• Fix - 버그/오류 해결
• Refactor - 코드 리팩토링 (멘토 리뷰 반영 / 스스로 리팩토링 / 중복 코드 제거 / 불필요 코드 제거 / 성능 개선)
   

작은 프로젝트에서는 보통 위 5가지의 규칙만으로도 충분했었는데,
팀으로 개발을 하고 프로젝트의 크기가 커지면서, 위 규칙만으로는 부족함을 느끼게 되었다.

정보 인용

그러다 며칠 전, Git 커밋 메시지 자동화 가이드 | DevSecOps 구축 컨설팅, 교육, 기술지원 서비스 제공 이란 아주 유용한 글을 보게 되었다.

그 중, git commit 메세지 작성시 제목줄의 컨벤션 부분을 정리하며 앞으로의 개인 개발시 사용해보고자 한다.

✨ Feat(페이지 경로 또는 컴포넌트): 새로운 기능 추가 또는 기능 업데이트
🔨 Fix(페이지 경로 또는 컴포넌트): 버그 또는 에러 수정
⭐️ Style(페이지 경로 또는 컴포넌트): 코드 포맷팅, 코드 오타, 함수명 수정 등 스타일 수정
🧠 Refactor(페이지 경로 또는 컴포넌트): 코드 리팩토링(똑같은 기능인데 코드만 개선)
📁 File(페이지 경로 또는 컴포넌트): 파일 이동 또는 제거, 파일명 변경
🎨 Design(페이지 경로 또는 컴포넌트): 디자인, 문장 수정
🏷 Comment(페이지 경로 또는 컴포넌트): 주석 수정 및 삭제
🍎 Chore: 빌드 수정, 패키지 추가, 환경변수 설정
📝 Docs: 문서 수정, 블로그 포스트 추가
🔥 Hotfix: 핫픽스 수정

그리고 여기에 더해 따로이 추가할까 고민중인 메세지

🔧 Modify(페이지 경로 또는 컴포넌트): 기능 변경 또는 기능 업데이트

적용전 고민

Modify라는 타이틀은 사실 위에서 정의한 Feat의 ‘기능 업데이트’ 라는 부분에서 성격이 겹친다.
이 부분을 고민하는 이유는 기능 업데이트 라는 부분의 제목 분류를 따로 할 것인가 Feat에 포함시킬 것인가라는 의문에서 나왔다.

실제로 지금까지 개발을 하며 git을 다루어본 경험으로,
Pull Request에서는 기능 소개나 버그 수정이 주가 될 수 있지만,
일반적인 Commit message에서는 기능개선, 수정 등이 주가 되었다.
즉, Modify가 가장 많단 말이 된다.

이 때, 이 모든 것을 Feat으로 처리하면 실제로 커밋 메세지를 쭉 훑어나가면서 하나의 기능이 언제 처음 추가가 되었고, 어떻게 변경되어 나가는가를 살피기에 Modify라는 제목 분류가 훨씬 더 보기 편하였다.
 
 

정리

때문에 끝으로 결정하였던 나의 Commit Message 규칙은 다음과 같이 정리되었다.

정작 위 방식을 쓰려고 하면 매번 git commit message를 작성할 때마다 해당 컨벤션을 기억해내야하고 또 해당 이모지를 찾아서 입력을 해야하는 수고로움이 생길 수 있다.

물론 메모장 같은 곳에 따로 메모를 해놓고 그때그때 살펴보며 복사-붙여넣기를 할수도 있겠지만,
Gitmoji라고 해서 링크의 글을 가보면 IntelliJ에 Plugins로 추가설치하여 사용할 수도 있다.

하지만 플러그인 방식은 다른 IDE를 사용하거나 일반적인 터미널에서는 사용하기가 애매해서 나는 이를 Alfred app의 Snippets 기능을 활용한 상용구 방식으로 입력할 수 있도록 세팅하였다.

git commit은 한번에 뭉쳐서 하기보다 성격에 따라 세세하게 나눠 기록하는 것이 추후 유지보수에 더 좋다는 글을 여러 번 봤는데, 실제로 뭉쳐진 commit은 나중에 추적하기 여간 불편한게 아니었다.

될 수 있으면 간단하면서도 알아보기 쉬운 설명으로 메세지를 기록하고,
이 때 머릿글이 되는 제목줄의 위와 같은 컨벤션이 앞으로의 개발 과정에 더 큰 도움이 되리라 기대된다.