커밋 메시지 컨벤션 (구조, 타입)

커밋 메시지가 중요한 이유

잘 작성된 커밋 메시지(commit message)는 소프트웨어 개발에서 프로젝트 관리, 협업 커뮤니케이션 측면에서 매우 중요합니다. 커밋 메시지를 잘 작성하게 되면 개발자가 변경 사항을 이해하고, 효과적으로 협업하고, 문제를 디버그하고, 코드 기록을 추적하는 데 도움이 됩니다. 훌륭한 커밋 메시지는 코드 리뷰, 프로젝트 관리 및 유지 보수를 원활하게 해줍니다.

좋은 커밋 메시지를 위한 7가지 규칙

Chris Beams의 'How to Write a Git Commit Message'라는 블로그 포스트에서는 좋은 커밋 메시지를 위한 7가지 규칙을 제안합니다.

How to Write a Git Commit Message

1. 제목과 본문은 공백으로 구분한다

2. 제목은 영문 기준 50자 이내로 제한한다

3. 제목의 첫 글자는 대문자로 작성한다

4. 제목 줄은 마침표로 끝내지 않는다

5. 제목은 명령 형태로 작성한다

6. 본문은 영문 기준 72자마다 줄 바꾸기를 진행한다

7. 본문에는 어떻게(how)보다 무엇을(what)과 왜(why)에 대해서 설명한다

위의 규칙을 담은 커밋 메시지 예시

Refactor login process

Separate the login functionality into smaller functions
to improve code readability and maintainability.

- Created separate functions for input validation, authentication,
  and session management.
- Removed redundant code and consolidated error handling.

Addresses issue #123

커밋 메시지 구조

Conventional Commits. Udacity Git Commit Message Style Guide 등의 게시물에서는 커밋 메시지 구조를 더욱 구체적으로 제안합니다.

 

Conventional Commits

<타입>[범위(선택 사항)]: <제목>
<한줄 공백>
<본문(선택 사항)>
<한줄 공백>
<꼬리말(선택 사항)>

feat: 새로운 기능의 추가, 삭제, 변경(제품 코드 수정)
fix: 버그 수정(제품 코드 수정)
docs: 문서 추가, 삭제 변경(제품 코드 수정)
style: 포맷, 정렬 등의 변경과 같이 스타일과 관련된 수정(제품 코드가 수정되지만 동작에 영향 없음)
refactor: 코드 전면 수정(리팩토링, 제품 코드 수정)
test: 시험을 위한 코드 추가, 삭제, 변경(제품 코드 수정 없음)
chore: .gitignore 파일처럼 외부 사용자가 관심 없는 파일이나 빌드, 패키지 매니저, CI 등과 관련된 파일의 변경(제품 코드 수정 없음)
---------------
hotfix: 급하게 치명적인 버그 수정
rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
remove: 파일을 삭제하는 작업만 수행한 경우
comment: 필요한 주석 추가 및 변경

위 타입들은 권고사항이며 프로젝트 특성에 맞게 타입 종류를 설정해 주시면 됩니다. 위의 커밋 메시지 예시에서도 불 수 있듯이, 꼬리말 부분에는 이슈 트래커와 함께 사용할 때 해결한 이슈나 참고할 부분을 명시해 주면 좋습니다.

Resolves: #123
See also: #456, #789