git Commit Message 작성 방법

커밋 메시지

커밋의 컨벤션은  커밋 메시지안에 기능, 수정사항 및 주요 변경 사항을 설명해야 됩니다.

커밋 메시지의 양식은 아래의 양식 처럼 구성해야 합니다.

---

<타입> [optional scope]: <설명>

[optional body]

[optional footer]

---

커밋은 해당 라이브러리의 소유자에게 의도를 전달하기 위해 다음과 같은 구조요소를 설명해야 합니다.

1. fix: fix: 유형의 커밋은 해당 코드베이스의 버그를 수정하다는 의미.
2. feat: feat: 유형의 커밋은 해당 코드베이스의 새로운 기능을 추가한다는 의미.
3. BREAKING CHANGE: BREAKING CHANGE: 는 footer에 추가하거나 type/scope 에  ! 를 붙이고 추가한다. 해당 커밋은 새로운 버전으로 import해주거나 추가로 다른 모듈을 추가해주거나 제거해야하는 변화를 의미한다.
4. 예외로 build: , chore: , ci: , docs: , style: , refactor: , perf: , test: 등이 있습니다
5. BREAKING CHANGE를 제외한 바닥글에는 https://git-scm.com/docs/git-interpret-trailers에 있는 git trailer format 컨벤션을 따른다.

 

Examples

---

새로운 기능 설명 그리고 Breaking change에 대한 커밋 메시지

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

 

변경 사항이 돋보이도록 !를 사용한 커밋 메시지

refactor!: drop support for Node 6

 

변경사항이 돋보이도록 !를 사용한 커밋 메시지(scope 추가)

refactor(runtime)!: drop support for Node 6

 

!와 BREAKING CHANGE(footer)를 사용한  커밋 메시지

refactor!: drop support for Node 6

BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.

 

Body가 없는 커밋 메시지

docs: correct spelling of CHANGELOG

 

Body가 없는 커밋 메시지(Scope 추가)

feat(lang): add polish language

 

여러 줄의 Body와 여러 줄의 footer를 가진 커밋 메시지

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

 

설명

---

• 커밋 앞에서는 feat, fix와 같은 커밋 유형이 접두사로 붙어야 한다. 그뒤에는 선택적으로 scope나 !를 붙이고 :(콜론)이 와야 한다.
• feat 커밋은 애플리케이션이나 라이브러리에 새 기능을 추가할 때 사용해야 합니다.
• fix 커밋은 애플리케이션이나 라이브러리의 버그를 수정할 때 사용합니다.
• Scope는 커밋의 유형 뒤에 사용해야 합니다.
• Description은 type(scope): 뒤에 바로 와야합니다. (변경사항 요약)
• 코드 변경에 대한 자세한 내용은 Descroption 아래의 줄바꿈으로 들어가야합니다 (OPTIONAL Body)
• 커밋 본문(Body)은 자유로운 양식으로 작성할 수 있습니다.
• 한개 이상의 Footer는 본문(Body)아래의 한줄의 공백 뒤에 추가 할 수 있습니다. 또한 구분 기호: 값의 형태로 작성해야 한다.
• Footer의 토큰은 공백대신 - 를 사용합니다. (예: Acked-by)
• Footer 값에는 공백과 줄바꿈이 포함될 수 있으며, 다음 Footer에 값이 발견한다면 구문 분석은 종료되어야 합니다.
• 주요 변경 사항(BREAKING CHANGE)는 커밋의 type(scope) 또는 Footer에 표시해야 합니다.
• 주요 변경 사항(BREAKING CHANGE)이 커밋의 접두사[type(scope)]에 포함 되는 경우 ! 를 붙여야 합니다.
• feat 이외에 유형을 커밋 유형에 사용할 수 있습니다(예 docs, refactor, fix 등)
• 기존 커밋을 구성하는 정보 단위는 BREAKING CHANGE를 제외하고 대문자로 표현하는 것을 금지합니다.
• BREAKING-CHANGE는 Footer에서 사용될 때 다른 단어로 대체하면 안됩니다.

 

Conventional Commits을 사용하는 이유

---

• 깃허브에 자동화된 CHANGELOG들을 사용할 수 있다.
• 자동화된 Version bump(프로그램 버전 번호를 증가)를 사용 할 수 있습니다.
• 팀, 사용자 들에게 의미 있는 변경 사항을 전달 하기 위함입니다.
• 빌드 및 게시 등의 트리거를 작동하기 위함 입니다.
• 구조화된 커밋 기록을 통해 사람들이 프로젝트에 쉽게 기여할 수 있습니다.

 

git 명령어를 통한 부가 설명 다는 방법

git commit -m "커밋 제목

부가 설명"

 

 

 

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

Conventional Commits