아래와 같이 조금 더 디테일하게 적어줄 수 있을 것 같다. 이전에는 feat, docs, style, chore 등은 쓴 적이 없고 Delete, Add, Fix, Test와 같은 type만 적어줬는데 아래 처럼 feat, docs, refactor 등을 활용할 수 있을 것 같다.
이모지로 표현하는건 개인적으론 별로 좋지 않은것 같다. 근데 이건 그냥 개인 취향이라 하고 싶은 사람은 팀에서 잘 논의해서 결정하면 될 것 같다.
아래 양식 정도만 따르면 큰 문제는 없을 것 같다.
- feat : 새로운 기능 추가
- fix : 버그 수정
- docs : 문서 수정
- style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
- refactor : 코드 리펙토링
- test : 테스트 코드, 리펙토링 테스트 코드 추가
- chore : 빌드 업무 수정, 패키지 매니저 수정
그리고 한 가지 주의할건.
마침표는 찍지 말자.
커밋 메시지에 대한 7가지 규칙을 소개한 블로그가 있었다.
내용은 아래와 같다.
1. 제목과 본문을 빈 행으로 구분합니다.
2. 제목을 50글자 이내로 제한합니다.
3. 제목의 첫 글자는 대문자로 작성합니다.
4. 제목의 끝에는 마침표를 넣지 않습니다.
5. 제목은 명령문으로써 과거형을 쓰지 않습니다.
6. 본문의 각 행은 72글자 내로 제한합니다.
7. 어떻게 보다는 무엇과 왜를 설명합니다.
아래 블로그에서 많은 도움을 받았습니다.
감사합니다.
https://da-nyee.github.io/posts/git-git-commit-message-convention/
https://koreapy.tistory.com/1150
반응형
'인프라 > Git' 카테고리의 다른 글
[Git] 협업 방식 정리(1) git + gitflow + gitlab + 코드 리뷰 + code convention + PR Request + Merge Request + 개발 문화 (0) | 2023.02.15 |
---|---|
[Git] git flow model (0) | 2023.01.01 |
[Git] git local default branch 변경과 remote default branch 변경 (0) | 2022.10.31 |
[Git] Hyper-v 설정 적용 이후 Git push 에러 (0) | 2022.09.21 |
[Github] private repository 에 push하기 + ssh-keygen (0) | 2022.08.18 |