> For the complete documentation index, see [llms.txt](https://noah-dev.gitbook.io/til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://noah-dev.gitbook.io/til/git-and-github/git/commitmessage.md).

# 규칙적인 깃 커밋 메세지 작성하기

## 1. 개요

규칙을 정해 커밋 메세지를 작성하면 어떤 기능이 추가되었는지 어떤 버그가 수정되었는지 어떤 리팩토링을 했는지 알 수 있다.

많은 곳에서 사용되고 있는 **규칙적인 깃 커밋 메세지를 작성하는 방법**에 대해 살펴본다.

***

## 2. 커밋 메세지의 7가지 규칙

1. 제목과 본문을 빈 행으로 구분한다.
2. 제목을 50글자 이내로 제한한다.
3. 제목의 첫 글자는 대문자로 작성한다.
4. 제목의 끝에는 마침표를 넣지 않는다.
5. 제목은 명령문으로 작성하고 과거형을 사용하지 않는다.
6. 본문의 각 행은 72글자 내로 제한한다.
7. 어떻게 보다는 무엇과 왜를 설명한다.

***

## 3. 커밋 메세지의 구조

```md
타입(Type): 제목(Subject)

본문(Body)

꼬리말(Footer)
```

***

### 3-1. 타입(Type): 제목(Subject)

`타입(Type)`은 해당 커밋의 성격을 나타낸다. `타입(Type)`의 종류는 아래와 같다.

* feat: 새로운 기능 추가
* fix: 버그 수정
* build: 빌드 관련 파일 수정
* ci: ci관련 설정 수정
* docs: 문서 추가, 수정, 삭제
* style: 스타일(코드 형식, 세미콜론 추가 등과 같은 비즈니스 로직에 변경 없는 경우)
* refactor: 코드 리팩토링
* test: 테스트 코드 추가, 수정, 삭제
* chore: 기타 변경사항

`제목(Subject)`은 커밋 메세지를 대표한다. 간결하고 `2. 커밋 메세지의 7가지 규칙`에 맞게 작성한다.

`타입(Type): 제목(Subject)` 예시

> feat: 학생의 알러지를 검사하는 함수 추가

***

### 3-2. 본문(Body)

* 선택사항이며 제목에서 생략한 상세한 내용을 작성한다.
* 설명뿐만 아니라, 커밋의 이유를 작성할 때에도 쓴다.

`본문(Body)` 예시

> feat: 학생의 알러지를 검사하는 함수 추가
>
> 식단표의 알러지 보기 기능을 추가하기 위한 함수 추가

***

### 3-3. 꼬리말(Footer)

* 선택사항이므로 모든 커밋에 꼬리말을 작성하지 않아도 된다.
* issue tracker ID를 작성할 때 사용한다.
* 해결: 이슈 해결 시 사용
* 관랸: 해당 커밋에 관련된 이슈 번소
* 참고: 참고할 이유가 있는 경우 사용

`꼬리말(Footer)` 예시

> feat: 학생의 알러지를 검사하는 함수 추가
>
> 식단표의 알러지 보기 기능을 추가하기 위한 함수 추가
>
> 참고: #123

***

## 4. 규칙적인 깃 커밋 메세지의 이점

* 팀원과의 원활한 소통
* 편리한 과거의 기록 추적
* 이슈와 관련된 진행 사항 확인

***

## 5. ETC - 리팩토링

feat과 refactor을 구분하기 위해 추가적으로 공부한 내용을 정리한다.

### 5-1. 리팩토링을 해야 할 때

1. The Rule Of Three: 유사한 내용이 세번 이상 반복할 때
2. 새로운 기능을 추가할 때\
   현재 소스코드에서 새로운 기능을 추가하기 어려워 보이면, 리팩토링을 한다.
3. 코드리뷰를 할 때

***

### 5-2. Two Hats

![Two Hats](https://3395804243-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtlrW8c4MEVWoel5YVxSk%2Fuploads%2Fgit-blob-8495e0df4b8f74d85173362cbfffe19cb79eeeab%2FTwoHats.png?alt=media)

* 기능을 추가할 때: 기존코드를 수정하지 말고, 기능과 테스트만 추가
* 리팩토링을 할 때: 기능과 테스트를 추가하지 않기

> 리팩토링을 하면서 기능을 추가하는 것이 아니라 기능단위로 추가, 테스트 후 리팩토링을 해야한다.

***

## 6. Conclusion

> 지금까지 많은 커밋 메세지를 작성했었다. 하지만 어떤 규칙이 없었으며 기능 단위로 하지도 않았다. 즉, 내가 하고 싶을 때마다 했다. 그래서 어떤 코드가 변경이 되었는지 과거를 거슬러 올라가야 할 필요가 있을 때 하나하나 찾아봐야해서 시간이 많이 걸렸다. 물론 지금까진 주로 혼자서만 프로젝트를 진행했기 때문에 큰 문제는 없었다. 앞으로 개발자가 되어 동료들과 함께 프로젝트를 진행하게 될 텐데 미리 규칙적인 커밋 메세지를 작성하는 방법을 숙지해야 겠다. 그리고 티처캔에도 도입을 해봐야겠다.\
> 위의 내용은 구글링을 통해 널리 사용되고 있는 커밋 메세지 작성 방법으로 보인다. 이보다 더 중요한 건 이후에 내가 들어갈 팀에서 정한 규칙이다.

***

## 참고

[\[Git\] 규칙적인 Commit 메세지로 개발팀 협업하기👾](https://xtring-dev.tistory.com/entry/Git-%EA%B7%9C%EC%B9%99%EC%A0%81%EC%9D%B8-Commit-%EB%A9%94%EC%84%B8%EC%A7%80%EB%A1%9C-%EA%B0%9C%EB%B0%9C%ED%8C%80-%ED%98%91%EC%97%85%ED%95%98%EA%B8%B0-%F0%9F%91%BE)\
[GitHub commit 메세지 규칙](https://junhyunny.github.io/information/github/git-commit-message-rule/)