#1. commit convention, 중요한가?
혼자 개발한다면 commit message를 아무렇게나 작성해도 자신은 이해할 수 있지만 시간이 오래 지나거나 같이 보는 팀원이 생긴다면 보기 어려울 수가 있다.
스스로에게도 convention을 지켰을 때 가장 좋은 점이 전에 작성해놨던 구현 코드들을 다시 사용하고 싶을 때 정릴르 제대로 해놓으면 쉽게 찾아 쓸 수 있기 때문에 굉장히 중요한 부분이다.
#2. 커밋메세지 구조 알아보기
커밋 메세지 구조는 크게 3가지로 나뉜다 => (제목, 본문, 꼬리말)
type: subject -> 제목
(한칸 띄워야 한다)
body -> 본문
(한칸 띄워야 한다)
footer -> 꼬리말1) type
feat : 새로운 기능을 추가할 때
fix : 버그 수정했을 때
refactor : 리팩토링했을 때
design : 사용자 UI 디자인 변경됐을 때 (css 등)
comment : 필요한 주석 추가 혹은 변경되었을 때
style : 코드 포맷팅, 세미콜론 누락되거나 코드 변경이 없는 경우
test : 테스트 코드 추가/수정/삭제, 비즈니스 로직에 변경이 없는 경우
init : 프로젝트 초기 생성했을 때
rename : 파일/폴더명을 수정했거나 옮겼을 경우
remove : 파일을 삭제하는 작업만 수행했을 경우
chore : 위에 나열한 것중에 걸리지 않는 기타 변경사항이 발생했을 경우
2) subject
- 제목은 최대 50글자 이상 넘어가지 말기
- 마침표나 특수기호는 사용하지 말기
- 첫 글자는 대문자 혹은 명령어로 사용하기 - 과거시제 사용X (예 : "Fixed" => "Fix")
- 개조식 구문으로 작성하기(간결하고 요점적으로)
3) body
이 부분은 선택사항이기 때문에 모든 커밋부분에 본문내용을 작성할 필요는 없다. 부연설명이 필요하거나 이유를 설명해야할 경우 작성해주는 부분이다.
<body rule>
- 한 줄당 72자 내로 작성하기
- 최대한 상세히 작성하기
- '무엇을', '왜' 변경했는지에 대해 작성하기
4) footer
이 부분도 선택사항이고 모든 커밋에 꼬리말을 작성할 필요는 없다. issue tracker ID 를 작성할 때 사용한다.
<footer rule>
- 유형 : #이슈 번호 형식으로 작성하기
- issue tracker ID를 작성하기
- 여러 개의 이슈 번호는 ,로 구분하기
* issue tracker 유형
Fixes : (아직 해결되지 않은 경우) 이슈 수정중일 때 사용
Resolves : 이슈를 해결했을 때 사용
Ref : 참조할 이슈가 있을 때 사용
Related to : (아직 해결되지 않은 경우) 해당 커밋에 관련된 이슈 번호
참고)
footer에 Fixes: : #1이라고 작성하고 커밋하면 자동으로 issue #1과 매칭
여기에다 Resolves : #1으로 이슈를 해결했다 명시하면 그 이슈는 사라지게 만들었다..!
#3 쓰기 좋은 커밋 템플릿과 적용방법
# 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping
# 본문은 아래에 작성
# 꼬릿말은 아래에 작성: ex) Github issue #23
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor : 리팩토링
# design : CSS 등 사용자 UI 디자인 변경
# comment : 필요한 주석 추가 및 변경
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 수정 (문서 추가, 수정, 삭제, README)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)
# init : 초기 생성
# rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우
# remove : 파일을 삭제하는 작업만 수행한 경우
# ------------------
# 제목 첫 글자를 대문자로
# 제목은 명령문으로
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------
# <꼬리말>
# 필수가 아닌 optioanl
# Fixes :이슈 수정중 (아직 해결되지 않은 경우)
# Resolves : 이슈 해결했을 때 사용
# Ref : 참고할 이슈가 있을 때 사용
# Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
# ex) Fixes: #47 Related to: #32, #21적용방법 :
1. 자기가 원하는 경로에 gitmessage.txt 파일을 생성한다
2. 내용은 위 템플릿을 사용하여 내용 삽입한다(#는 참고로 주석이다)
3. 터미널에 명령어를 입력한다
$ git config --global commit.template C:\.gitmessage.txt (예시로 C:/를 준 상태이고 실제로는 본인 결로에다가 적기)
이 설정을 통해 앞으로 $ git commit 명령어를 통해 앞전에 만들어뒀던 vim 메세지가 보일 것이다. 본인만의 템플릿으로 커스텀해서 간편하게 커밋할 수 있다
나의 생각 :
커밋 컨벤션을 정리해보니 협업할 때 남과 내가 알기 쉽게 정리하는 것이 얼마나 도움되는 행동인지 찾아보며 깨닫게 되었다. 이 뿐만 아니라 여러 컨벤션을 잘 숙지하고 적용해보고 나아가야 한다.
'GIT & GITHUB' 카테고리의 다른 글
| [git] ! [rejected] main-> main(non-fast-forward) error: failed to push some refs to 'https://github.com/~' 오류 해결 방법 (1) | 2024.02.12 |
|---|---|
| Git commit 메세지 잘못 입력했을 때 commit 수정해보기 (0) | 2024.02.02 |
| git init, status, .gitignore, add (0) | 2024.01.09 |