아래와 같이 조금 더 디테일하게 적어줄 수 있을 것 같다. 이전에는 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/
[Git] 깃 커밋 메시지 컨벤션 (Git Commit Message Convention)
Introduction
da-nyee.github.io
[협업] 협업을 위한 git 커밋컨벤션 설정하기
들어가며 어떻게 하면 협업을 더 잘할 수 있을까 고민하며 협업에 필요한 내용들을 계속 정리하고 있습니다. 앞으로 저와 함께 협업하는 팀원분들에게 도움이 되고 싶습니다. 이 글은 Udacity Git C
overcome-the-limits.tistory.com
https://koreapy.tistory.com/1150
[Git] Git 커밋 메시지 컨벤션 예시 (협업)
규칙적인 Commit 메세지로 개발팀 협업하기 👾 TL;DR 개발자들은 Github를 통해 git에 대한 활동을 확인할 수 있습니다. 코드의 최신화 유지와 문제 원인 발견, 신규 기능 추가에 대한 branch 분리 전략
koreapy.tistory.com
'인프라 > 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 |