[Git] 커밋 메세지 컨벤션(Commit Message Convention)

면접을 보다가 질문 중에 하나가 커밋 컨벤션에 대해서 질문이 나왔었다.

커밋 컨벤션을 알고 있는지, 왜 쓰면 좋은지에 대해서 물어본거 였는데,

사실 커밋을 기능단위로 쪼개는 등 이런 생각은 많이해왔지만 특별하게 어떠한 규칙으로 해봐야겠다는 생각은 구체적으로 해보지 않았다. 그래서 커밋컨벤션에 대해서 정리해보고자 한다.

(이렇게 면접으로 지식과 반성이 +1 됩니다)

 

Commit convention이라고 검색을 해보면 가장 먼저 나온 conventionalcommits.org 를 기반으로 하였다.

https://www.conventionalcommits.org/en/v1.0.0/

Conventional Commits

 

일단 커밋 컨벤션을 할 때의 장점

: 커밋을 통해서 작업단위를 구분할 수 있도록 도와준다. ( 커밋의 타입을 지정할 때, 해당 커밋만 들어가도록 생각하기 때문에 작은 단위로 커밋을 분리하고 설명을 자세히 쓸 수 있기 때문!)

또 커밋을 정리하고 관리할 수 있도록 도와줄 수 있다고 생각한다. 깃헙에서 커밋을 검색할 수 있는데 여기서 동일한 레이아웃의 커밋으로 작성하게 되면, 찾기가 쉬울 것 같다.

빌드와 배포 프로세스에서 어느 부분까지 배포할지 빌드할지 정할 수 있는 기준이 된다.

협업할 때, 다른 동료 개발자가 무엇을 수정했는지 등을 쉽게 알수 있도록 해준다.

 

그렇다면 커밋 메세지는 어떻게 작성하는 것이 좋을까?  위의 홈페이지에 따르면 커밋의 구조는 아래처럼 작성하도록 권고한다.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

 

1. <type> 

  타입은 커밋의 종류를 의미하는데 가장 기본적으로 커밋을 검색하기에 가장 큰 역할을 수 할 수 있을 것 같다.

  타입의 종류는 아래와 같다.

  - fix : 버그 패치

  - feat : 새 기능 추가

  - docs : 문서 수정

  - refactor : 버그도 아니고 새로운 기능이 추가되거나 그런게 아닌 코드 수정을 할 때

  - style :  코드의 전체적인 중요 변경되는 것이 아니라 스타일이나 세미콜론 안찍은거나 띄어쓰기 같은관련 수정

  - build : 빌드시스템에 변화가 있거나 외부 라이브러리를 추가했을 때

  - perf : 퍼포먼스 측면에서 코드에 변화를 주었을 때

  - test : 빠진 테스트나 테스트 코드를 수정할 때

 

2. [optional scope] 

  영향을 받은 npm 패키지 이름을 적는 것이라고함..!

  자세한 내용은 아래에서 확인이 필요함.

  https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines

 

3. <description>

  설명을 적는 부분

 

4. [optional body] 

  설명보다 더 자세하게 작성하는 바디 부분

  선택사항이라 적어도 되고 안적어도되고!

 

5. [optional footer]

  말꼬리 부분! 얘도 선택사항

 

 

**

엄청나게 크게 변화를 하는데 사람들이 알아줘야할 때에는 footer 영역에 BREAKING CHANGE: 라는 단어를 쓰고 뒤에 설명을 쓰거나

type을 적고 ! 를 붙여 넣는다.

약간 강조를 해주는 느낌으로 사용하면된다.