유지 보수 담당으로 들어가게 되며 기존의 커밋들을 참고해야 할 때가 있었는데
커밋메시지가 통일되어있지 않다 보니 찾아보는 게 어려웠다.
이번에 새로운 프로젝트에 들어가게 되면서 기본적으로 준비해야 할 것을 찾아보던 중
커밋 메시지 컨벤션이 있어서 간단하게 알아보았다.
우선 커밋 메시지 컨벤션이란,
말 그대로 커밋 메시지 + 컨벤션(convention, 협약)으로
협업하는 사람들끼리 커밋 메시지의 형식을 정하고 따름으로써 가독성 있는 커밋 메시지를 만들 수 있는 약속이다.
git commit -m "커밋메시지"에서 커밋메시지 부분을 컨벤션에 맞게 작성하면 된다.
0. 커밋 메시지의 기본 형식
<type>: <subject> -- 제목
<body> -- 본문(option)
<footer> -- 푸터(option)이러한 형식으로 커밋메시지 부분에 들어가게 된다.
1. 제목
1) type
(+) css등 ui 관련 커밋은 'style'!!!!
feat: 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정fix: 기능에 대한 버그 수정style: 코드 스타일, 포맷팅에 대한 수정docs: 문서(주석) 수정build: 빌드 관련 수정chore: 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignoreci: CI 관련 설정 수정refactor: 기능의 변화가 아닌 코드 리팩터링 ex) 변수 이름 변경test: 테스트 코드 추가/수정release: 버전 릴리즈
type을 작성할때는 바로 뒤의 세미콜론은 반드시 붙이고, 세미콜론 뒤에는 띄워쓰기를 해주면 된다.
ex. feat: add the ...
2) subject
- 제목과 본문 사이에 한 줄 띄워 구분할 것
- <subject>는 50자 이내로(eng) 작성할 것
- <subject>의 첫 글자는 대문자로 시작할 것
- <subject>의 끝에 마침표(.)는 붙이지 않을 것
- <subject>는 명령문으로 작성할 것
2. 본문
제목만으로 표현이 가능하다면 본문은 생략이 가능하다.
만약 부가적인 설명을 작성하고싶다면 '어떻게'보다는 '무엇을, 왜'에 대해 작성해야한다.
또한 본문의 각 행은 72자(eng) 이내로 작성해야한다 (초과 시 줄 바꿈)
3. 푸터
<유형>: #<이슈 번호>로 보통 작성한다. 여러개의 이슈 번호가 있는 경우에는 쉼표로 구분한다.
유형은 다음 중 하나를 사용한다.
Fixes: 이슈 수정중 (아직 해결되지 않은 경우)Resolves: 이슈를 해결했을 때 사용Ref: 참고할 이슈가 있을 때 사용Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
아직 낯설어서 그런지 쉽지가 않다.
깃모지까지는 쓰지 못할 것 같고, 간단한 것들만 정해서 메시지 컨벤션정도는 추진해봐야지!
참고
https://velog.io/@ninto_2/%EC%BB%A4%EB%B0%8B-%EC%BB%A8%EB%B2%A4%EC%85%98#2
✍ 커밋 컨벤션
"커밋 메세지 쓸 때도 컨벤션이 존재했다고..?😨"
velog.io
https://velog.io/@jiheon/Git-Commit-message-%EA%B7%9C%EC%B9%99
[Git] Commit message 규칙
개발을 하다보면 수 많은 commit message 를 작성하는데, 좋은 규칙이 없을까?
velog.io
'WHAT I LEARNED > etc.' 카테고리의 다른 글
| [REDUX] 초간단한 카운터로 Redux-toolkit 연습 (0) | 2023.01.10 |
|---|---|
| [VSCode] live server 에러 : Something is went wrong! Please check into Developer Console or report on GitHub. (0) | 2022.12.29 |
| VS Code 확장 프로그램 (0) | 2022.12.27 |
| [VSCODE] Git 연동하는 10K 없애는 방법 (VER. 윈도우) (0) | 2022.12.23 |
| 한글 입력시 왼쪽 상단에 글자입력되면서 밀리는 경우 해결방법 (0) | 2022.12.19 |