그동안 내 Git Repository의 Commit을 보면서 엉망으로 커밋 메시지가 작성되어 있어 커밋 메시지 규칙에 대해 알아보고 이를 적용해 보고자 한다.
Git에서 Commit 메시지를 일정한 형식으로 작성하는 규칙을 말한다. 관습적으로 사용하는 가이드라인이 있지만, 각 프로젝트에 따라 별도의 규칙을 만들어 적용하기도 한다.

깃을 사용하는 이유는 프로젝트 관리, 협업 등 다양한 이유가 있다. 모든 커밋 메시지가 "오류수정", "기능 추가" 이러한 방식으로 작성되어 있으면 직접 코드를 이해하고 협업을 원할하게 하기 어려울 것이다.
깃을 제대로 활용하려면 커밋 규칙을 잘 따르는 것이 중요하다.
커밋 메시지를 통해서 각 변경사항이나 추가된 기능, 오류 수정이 어떤 목적으로 이루어졌는지 알 수 있다.
특정 이슈에 대한 수정 내용을 찾을 수 있다.
다른 개발자들과 협업할 때, 커밋 메시지를 통해 다른 사람이 코드를 이해하는 데 도움이 된다.
이는 코드 리뷰나 병합을 할 때도 관리자가 적절하게 프로젝트를 관리하는 데 효율적이다.
일관된 커밋 메시지로 소스 변경 이력을 효율적으로 추적할 수 있다. 이를 통해 문제 발생시 더 빠르게 원인을 찾아 수정하고, 전반적인 프로젝트 안정성을 높일 수 있다.
커밋 메시지는 아래 양식을 따른다.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
<type>커밋 타입을 말한다. 아래는 내가 android에서 사용하기 위해 템플릿을 수정하였다.
[커밋 타입] 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그(에러) 수정)
# design : CSS, XML 등 사용자 UI 디자인 생성 및 변경
# refactor : 리팩토링
# style : 스타일 (theme, color 파일 구현, 수정: 비즈니스 로직에 변경 없음)
# docs : 문서 (Readme.md 추가, 수정, 삭제)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (build.gradle 수정)
# release : 버전 릴리즈
# (아래는 필요시 사용)
# rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 하는 경우
# remove : 파일을 삭제하는 작업만 수행한 경우
<description>변경 작업의 제목이나 간단한 요약을 작성한다. 50자 이내로 요약하여 작성한다. 마침표를 일반적으로 사용하지 않는다.
<body>선택 사항으로 작업한 내용이 복잡하거나 기록해 두어야하는 상세 내용이 있을 때 작성 한 줄당 72자 이내로 작성하는 것이 좋다. 무엇을 보단 왜? 에 대해 작성한다.
<footer>선택 사항으로, 코드 작업과 관련된 이슈나 참조 링크가 있을 때 작성한다.
이슈 생성시에는 (#123)과 같이 작성하고, 종료시에는 close #123 또는 resloves #123으로 작성한다.
참조시에는 ref 참조링크 와 같이 작성한다.
git commit -m "fix: 리사이클러뷰 데이터 로딩 이슈 수정
리사이클러뷰에서 데이터 로딩시에 중복 데이터가
생성되어지는 이슈 수정.
resolves: #123"
커밋 메시지 규칙들에는 정답은 없으며 팀원들이나 자신만을 일정한 규칙을 가지고 진행한다.
깃 커밋 메시지 규칙에 대해 알아보았으니 템플릿을 만들어서 자신의 프로젝트에 적용해 보면 좋을 것 같다.
템플릿 적용은 아래 링크를 참고하자.
깃 커밋 템플릿 만들어서 간편하게 커밋해보자!(https://jihyun-hamster.tistory.com/132)
다음의 링크를 참고했습니다.
Git 커밋 메시지 컨벤션은 왜 중요할까? - 위시켓
github.com/stephenparish/org-web/commits
깃 커밋 템플릿 만들어서 간편하게 커밋해보자! - jihyun-hamster
AngularJS Git 커밋 메시지 규칙