[Git] Conventional Commit

Conventional Commit은 Git 커밋 컨벤션 중 하나다.
이걸 꼭 써야하거나 하는건 아니고, 가이드라인 중 하나라고 보면 된다.
커밋 컨벤션 중에서는 가장 잘 알려져있고, 많이 쓰이고 있기도 하다.

이점

단순히 일관성을 위해서 사용할 수도 있지만, 이런 컨벤션을 정해서 사용하는 이유 중 하나는 잘 정립된 자동화 도구들을 사용하기 위한 것도 크다.

예를 들면 이런 거 말이다.
https://github.com/marketplace/actions/changelog-from-conventional-commits
이거 같은 경우에는 CHANGELOG 자동 생성 도구인데, 커밋이 잘 들어있을 것이라 가정하고 커밋 메세지들을 해석하고 모아서 자동으로 변경내역을 만들어주는 것이다.

기본 구조

기본 형태는 다음과 같다.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

간단한 커밋이라면 대충 이런 느낌이 된다.

feat: 로그인 API 구현

feat는 feature의 축약으로 그냥 기능 추가를 뜻한다.

feat(기능 추가)과 fix(문제 수정)가 가장 자주 쓰이는 편이고, build:, chore:, ci:, docs:, style:, refactor:, perf:, test: 같은 것들이 있다.
그 외에도 필요하다면 자체적으로 정의해서 써도 된다.

본문과 푸터까지 쓰면 또 이렇게 길게 쓸 수도 있다.

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

중간이 본문이고 아래가 푸터다.
body는 자유로운 형태로 계속 이어붙일 수 있고, 얼마든지 개행으로 구분할 수 있다.
푸터는 통상적으로 키: 값 쌍의 형태로 나열하고, 키값은 공백 대신 -를 써야 한다.

feat!: 로그인 API 구현

느낌표로 강조를 할 수도 있다.
보통 BREAKING CHANGE가 있어서 강조를 해야할때 주로 사용한다.

스코프

소괄호 스코프를 통해 해당 작업이 어디에 포함되는지 정할 수도 있다.
예를 들면 이런 식이다.

feat(auth): 로그인 API 구현

BREAKING CHANGE

만약 하위호한이 깨지는 변경이 포함된다면, BREAKING CHANGE 절에 해당 내용을 적어준다.

feat: 로그인 API 재구현

BREAKING CHANGE: 응답에 session 필드가 제거됨

Semver와 버전 생성

conventional commit은 Semver와 긴밀하게 엮여있다.
커밋 메세지를 기반으로 버전 생성을 결정할 수도 있게 하기 때문이다.

단순한 fix 커밋들만 있다면 버그 수정이므로 버전 생성시에 PATCH 릴리즈를 유도한다.
feat 커밋이 있다면 기능 추가이므로 MINOR 릴리즈를 유도한다.
BREAKING CHANGE가 있다면 하위호환이 보장되지 않으므로 MAJOR 릴리즈를 유도한다.

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