[ Git ] 깃허브 커밋 메시지 규칙

깃허브 커밋 메시지

팀 단위 프로젝트를 하다 보면 깃허브 커밋 메시지가 엉망진창이 되곤 한다!

잘 정리된 깃허브는 보기에도 좋고 버전 관리, 소스 코드 관리, 협업에도 무척이나 중요하다

 

나의 경우는 회사에서 혼자 한 프로젝트를 하고 있는데, 그래도 버전 관리 겸 깃허브에 코드를 커밋 중이다!

그러다 보니 아무래도 잘 정리된 것이 훨씬 보기 좋을 것 같고

나중에 팀 프로젝트를 맡게 된다면 더더욱 커밋 메시지 작성이 중요해질 것이게 때문에

 

이참에 깃허브 커밋 메시지 규칙을 정리해 보았다.

---

깃허브 커밋 메시지 규칙

제목과 본문 줄 바꿈

제목 50글자 이내

제목 첫 글자 대문자

제목 끝에 마침표 X

제목은 명령문, 과거형 X

본문 각 행 72글자 이내

왜, 무엇을 설명(어떻게 X)

 

---

깃허브 커밋 메시지 구조

Type(scope) : 내용					# 제목
# 줄 바꿈(enter)
어쩌구 저쩌구 설명					# 본문					
# 줄 바꿈(enter)
close #23111						# 바닥글

제목: 필수 입력, (scope)에는 소스코드 변경 위치(ex. login.js)를 적는데 생략 가능

본문: 설명 적기, 생략 가능

바닥글: 어떤 이슈에서 왔는지 등의 참조 정보 추가

 

* 이슈, 참조 키워드

Linking a pull request to an issue - GitHub Docs

---

깃허브 커밋 메시지 분류

type에 들어갈 문자들!문서마다 정해진 것들이 조금씩 다르고, 협업하는 사람들끼리도 조금씩 다른 것 같다참고해서 사용하면 될 듯!

 

 

FEAT

feature / 개선 또는 기능 추가

 

BUG / FIX

bug fix / 버그 수정

 

DOC / DOCS

documentation / 문서작업

 

TST / TEST

test / 테스트 추가, 수정

 

BLD

build / 빌드 프로세스 관련 수정

 

PERF 

performancee / 속도 개선

 

CLN

clean up / 코드정리, 리팩토링

*리팩토링 : 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.

 

 

 

---

 

깃허브 커밋 메시지 예시

#1
FEAT : Fix product update funciton


#2
DOC : Update README.md


#3
FEAT : Fix accidntal showing of Modal

Fix accidental showing of Modal when visibel prop
is undefined or null Fix crash when removing root
nodes

간단하게 적었는데 이런 식으로 사용하면 된다.