지금까지는 내 나름의 규칙으로만 커밋 메세지를 작성해왔다.
아직까지 규모가 큰 팀 프로젝트를 진행하지 않아 무리는 없었지만, 이제는 커밋 메세지를 올바르게 작성하는 방법을 참고해 항상 유의하면서 작성하는 연습을 해보는게 좋을 것 같다.
⚔️ 커밋 메세지의 7가지 규칙
- 제목과 본문을 빈 행으로 구분
- 제목을 50글자 이내로 제한
- 제목의 첫 글자는 대문자로 작성
- 제목의 끝에는 마침표를 넣지 않음
- 제목은 명령문으로! 과거형을 사용하지 않음
- 본문의 각 행은 72글자 내로 제한
- 어떻게 보다는 무엇과 왜를 설명
⚔️ 커밋 메시지 구조
헤더는 필수이며, 범위(scope), 본문(body), 바닥글(footer)은 선택사항
<type>(<scope>): <subject> -- 헤더
//<BLANK LINE>
<body> -- 본문
//<BLANK LINE>
<footer> -- 바닥글
알아보기 쉽게 예시로 보면, 다음과 같다.
Feat: 관심지역 알림 ON/OFF 기능 추가(#123)
시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함
- opnion0055: 구분 코드 해결: #123
//출처: https://xtring-dev.tistory.com/entry/Git-규칙적인-Commit-메세지로-개발팀-협업하기-👾 [xtring.dev]🗡 header
type
<type>은 해당 커밋의 성격을 나타내며 아래 중 하나여야 한다.
feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋scope
subject
🗡 body
<body>는 본문으로 헤더로 표현할 수 없는 상세한 내용을 적는다.
헤더로 표현이 가능하다면 생략 가능하다.
한 줄당 72자 이하로 작성하며, 깃이 자동 줄바꿈을 지원하지 않으므로 직접 줄바꿈을 해야 한다.
🗡 footer
<footer>는 바닥글로 어떤 이슈에서 왔는지 같은 참조 정보들을 추가하는 용도로 사용한다. (이슈 트래커 ID참조)
예를 들어 특정 이슈를 참조하려면 close #1233 과 같이 추가
close는 이슈를 참조하면서 main브랜치로 푸시될 때 이슈를 닫게 된다.
⚔️ 커밋 메시지 작성 예시
Reference
Why?에서 시작해 How를 찾는 과정을 좋아합니다. 그 고민과 성장의 과정을 꾸준히 기록하고자 합니다.