Blog

[Git]00 Commit 메시지 작성법 컨벤션

Category
Author
Tags
PinOnMain
1 more property
git을 통해 commit을 할 때 Commit 메시지를 작성하게 된다.
나는 깃을 혼자사용해왔기 때문에 사실 별로 신경쓰지 못했었다. 하지만 거의 메모장 수준으로 작성해왔고 항상 어떻게써야하지 생각을 해왔다.
하지만 개인 기록용이 아니라 협업에서는 이것도 하나의 커뮤니케이션 툴이며 공통된 규칙이 있어야 된다.
분명 회사마다 방식이 조금 다를 수도 있지만 기본적인 규칙을 다른 사람들은 어떻게 사용하는지 이번 기회에 올바른, 다른 사람들도 알아보기 편한 커밋 메시지 규칙들을 검색해보고 나도 실천하려고 한다.
기본 규칙
제목과 본문을 빈 행으로 구분
50글자 이하
대문자
마침표X
명령문
72글자 이하
무엇과 왜
Commit Message 구조 type : title(제목)
body(본문, 생략 가능)
Resolves : #issueNo, ...(해결한 이슈 , 생략 가능)
See also : #issueNo, ...(참고 이슈, 생략 가능)
Type 키워드
사용 시점
feat
새로운 기능 추가
fix
버그 수정
docs
문서 수정
style
코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)기능 수정이 없는 경우
design
사용자 UI 디자인 변경 (CSS 등)
test
테스트 코드, 리팩토링 테스트 코드 추가
refactor
코드 리팩토링
build
빌드 파일 수정
ci
CI 설정 파일 수정
perf
성능 개선
chore
빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정 등)
rename
파일 혹은 폴더명을 수정만 한 경우
remove
파일을 삭제만 한 경우
<label>:<title> # <label> 입력 목록 # 1. feat : 새로운 기능 # 2. bug : 버그 수정 # 3. update : 비즈니스 로직 변경 # 4. refactor: 리팩토링 # 5. docs : 문서 (문서 추가, 수정, 삭제) # 6. test : 테스트 # 7. etc : 기타 변경사항 # # <title> 규칙 # 1. 제목 길이 : 50자 # 2. 제목과 본문 사이 한 줄 띄워 분리 # 3. 제목 끝에 .(마침표) 금지 <description> # <본문 작성> 규칙 # 1. 내용의 길이는 한 줄당 60글자 내외에서 줄 바꿈. 한글로 간단 명료하게 작성 # 2. 어떻게 보다는 "무엇을", "왜" 변경했는지를 작성할 것 (필수) <issue-number> # <issue> 변경 # 1. 작성방법 : 키워드 #이슈번호 # 2. 연관된 이슈 첨부, 여러 개 추가 가능 # 3. 키워드로 Github 이슈(issue) 닫기 가능
Shell
복사
현재 내가 학습을 진행하면서는 내용이 많을테니 적용 시킬 만한 여러 템플릿을 살펴보았다.
우선 Type을 구분짓는게 필수적인것 같고, 내용을 간략하게 명령조로 작성해야겠다.
가장 아래있는 템플릿을 현재 적용 시키기 좋아 보여서 해당 방식을 우선 사용하고
곧 진행될 협업프로젝트시에도 해당 내용을 공유하고 어느정도 규칙을 만들어서 진행하면 좋을 것 같다.
커밋 후 좀더 찾아보니 대문자는 본문이었구나.. docs : Add gitignore … 처럼 사용되어야 한다.
또한 직접 작성하는 것보다 git config를 통해 템플릿을 활용 할 수 있다. 다음 글에서 정리하고자 한다.