[Git] git commit message convention에 대해 알아보기

지금까지 깃을 이용한 버전관리를 하면서 수많은 커밋을 했지만, 저장만 잘하면 되지 뭐~ 라는 생각으로 커밋 메시지 작성에는 크게 신경쓰지 않았다. 대충 전체적으로 포괄적인 메시지를 적거나 변경된 부분들 중 대표적으로 바뀐 부분만 적기도 하였다.

 

하지만 이번 팀 프로젝트를 진행하면서 다같이 하나의 프로젝트를 분할하여 진행하고 push하게 되니까, 서로가 어떤 부분을 어떤 목적을 가지고 어떻게 구현했는지 알아야 하는 상황이 되었다.

물론 데일리 스크럼을 통해서 현재 진행 중인 작업을 간단하게 공유하고 있지만, 더 구체적으로 github repo에서 직접 코드를 보고 어느 부분을 진행했는지 알 수 있는 방법으로 git commit message template을 사용하기로 했다.

 

이번 기회에 궁금했던 부분들, 그리고 설정/적용하는 방법을 남겨두려고 한다.

그러면 나중에 누군가(미래의 나 포함)가 보고 필요할 때 빠르게 사용할 수 있지 않을까? ㅎㅎㅎ

 

---

 

1. Code Convention (= Code Style Guide) 이란?

읽고 관리하기 쉬운 코드를 작성하기 위해서 사람들끼리 정해놓은 코딩 스타일 규약(하나의 작성 표준)이다.

즉, 내가 작성한 코드를 다른 사람들이 봤을 때 쉽게 이해할 수 있도록 가독성 있는 코드를 작성하기 위해 생긴 스타일 가이드 이다.

 

2. Git Commit Message Convention 이란?

git 을 사용하여 코드의 버전을 관리하거나 협업 관리할 때 사용되는 commit message 작성 방법에 대한 규칙이다.

이러한 컨벤션을 따르면

코드 변경 이후, 타인에게 코드 변경 사항을 설명할 때 용이하고 (나중되면 내가 개발한 코드여도 다 까먹으니까,,)

코드 리뷰를 하거나 버전 업데이트, 버그 발생시 문제 추적에 용이하다.

즉, 메시지를 구조화하고 일관성 있게 작성할 수 있도록 돕는 코드 스타일 가이드 이다.

 

(1) Commit message의 기본적인 구조

제목(header), 본문(body, optional), 꼬리말(footer, optional) 3가지의 파트로 나뉜다. 

type : description

body 

footer

• 제목(header) : [type: description의 형태] 해당 커밋에 대해 간결하게 설명한다. 50자 이내로 작성한다.
  • [참고] VSC editer를 사용한다면 왼쪽의 git source control을 이용해서 commit message 작성할 수 있다. 이때 작성된 메시지는 오로지 header로만 인식된다.

• 본문(body, optional) : 제목 이외에 추가 설명이 필요한 경우 작성한다(optional). 제목과 본문은 빈 줄(##########)로 구분한다.
• 꼬리말(footer, optional) : 커밋과 관련된 이슈 번호, 참고 등과 같이 추가 정보를 기록할 때 사용한다.

(2) type (in header) 의 종류

type은 영어로 쓴다.

(첫 문자는 대문자로 하는게 원칙인 것 같은데, 사실 대부분 소문자로 써서 대/소문자는 상관 없는 듯)

 

1️⃣ 주로 사용 타입 종류

Feat : 새로운 기능 추가
Fix : 버그 수정
Docs : 문서 수정
Style : 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는 경우
Refactor : 코드 리팩토링
Test : 테스트 코드, 리펙토링 테스트 코드 추가
Chore : 빌드 업무 수정, 패키지 매니저 수정

 

2️⃣ 그 외 기타 타입 종류

Design : UI 디자인 변경
Rename : 파일/폴더 이름 수정
Remove : 코드/파일 삭제

(3) description (in header) 의 규칙

[영어로 작성하는 경우]

1. 50자 이하, 대문자 작성, 마침표를 붙이지 않는다.

2. 과거형을 사용하지 않고, 명령조로 시작한다.

 

예시는 아래와 같다.

# 새로운 기능 추가
feat(user-auth): implement user login functionality

# 버그 수정
fix(order-processing): resolve issue with order calculation

# 코드 리팩토링
refactor(api): optimize database query performance

# 테스트 변경
test(login): add unit tests for user login functionality

[한글로 작성하는 경우]

1. 50자 이하, 마침표를 붙이지 않는다.

2. 과거형(ex. '~했습니다.')을 사용하지 않고 '동명사'로 끝내도록 한다.

 

예시는 아래와 같다.

# 새로운 기능 추가
feat(user-auth): 사용자 로그인 기능 구현

# 버그 수정
fix(order-processing): 주문 계산과 관련된 문제 해결

# 코드 리팩토링
refactor(API): 데이터베이스 쿼리 성능 최적화

# 테스트 변경
test(login): 사용자 로그인 기능에 대한 유닛 테스트 추가

(4) body 의 규칙

1. 선택사항(optional)이다. (꼭 작성 안해도 된다.)

2. 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성하면 된다.

3. 72자 이내로 작성한다.

3. 본문 내용은 어떻게 변경했는지 보다, "무엇을" 변경했는지 또는 "왜" 변경했는지 를 설명한다. (최대한 상세히 작성)

4. 제목과 구분되기 위해 공백 한 줄을 띄워서 작성한다.

 

(5) footer 의 규칙

1. 선택사항(optional)이다. (꼭 작성 안해도 된다.)

2. issue tracker id 를 작성할 때 "유형: #이슈번호" 형식으로 사용한다.

3. 여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.

 

[issue tracker 유형은 다음 중 하나를 선택한다.]

- Fixes: 이슈 수정 중 (아직 해결되지 않은 경우)

- Resolves: 이슈를 해결한 경우

- Ref: 참고할 이슈가 있는 경우

- Related to: 해당 커밋과 관련된 이슈번호 (아직 해결되지 않은 경우)

➡️ ex) Fixes: #45 Related to: #34, #23

 

 

 

 

여기까지가 Git commit message convention에 대해 알아보았다.🧚

 

이제 다음 포스팅(https://kkangsg.tistory.com/99)에서 

위의 convention을 따르는 Git commit message template 전체를 살펴보고

global과 local에 적용해서 앞으로 나의 프로젝트에 commit message template을 적용해보자!🔥

 

 

---

[참고]

• Git Convension
  • https://udacity.github.io/git-styleguide 
  • https://velog.io/@archivvonjang/Git-Commit-Message-Convention
• Gitmoji 사용
  • https://github.com/carloscuesta/gitmoji 
  • https://treasurebear.tistory.com/70
• Git commit message template
  • https://git-scm.com/book/ko/v2/Git%EB%A7%9E%EC%B6%A4-Git-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0