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

사용자 Mgmix

·

2020. 8. 5. 16:21

 

 

Git으로 작업을 하다 보면, 커밋 메시지 컨벤션을 정할 때 종종 고민이 되곤 합니다.

커밋 메세지 컨벤션을 정의한 스타일 가이드가 많이 있지만 많이 사용되는 스타일을 정리해 보았습니다.

 


Udacity Git Commit Message Style Guide

유다시티의 커밋 메시지 스타일 가이드입니다.

 

- 메시지의 구조

type: subject

body

footer

 

작성 방법 

- 제목에 포함되는 유형(Type) :

  • feat: 새로운 feature 
  • fix: 버그 등 수정 
  • docs: 문서 내용 변경 
  • style: 포맷,  세미콜론 수정 등 코드가 아닌 스타일에 관련된 수정
  • refactor: 리팩토링 코드
  • test: 테스트 코드 추가 및 리팩토링 테스트 등
  • chore: build task 수정, 프로젝트 매니저 설정 수정 등

- 제목(Subject):

제목은 50자 이내로, 대문자로 시작하며 마침표로 끝나지 않도록 합니다.

의무적 어조로 작성하며 커밋이 무엇을 했었는지를 설명하는 형태가 아닌 무엇을 했는지를 설명해야 합니다.

(예를 들면 '수정했음', '수정함' 등이 아닌 '수정'으로 사용합니다)

 

- 내용(Body):

일반적으로 제목까지만 기재하면 충분하기 때문에 선택사항으로 기재하면 되며, 약간의 설명이나 전체 문맥을 설명해야 할 때만 사용합니다. 작성할 때는 커밋에 대해 어떻게(How)가 아닌 무엇(What) 그리고 이유(Why)에 설명을 합니다.

 

- 마무리(Footer)

푸터는 내용과 같이 선택 사항이며, 이슈 트랙킹을 위해 ID 등을 참조할 때 사용됩니다 ( #382, #188...) 

 

예시

feat: Summarize changes in around 50 characters or less  More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together.  Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequenses of this change? Here's the place to explain them.  Further paragraphs come after blank lines.   - Bullet points are okay, too   - Typically a hyphen or asterisk is used for the bullet, preceded    by a single space, with blank lines in between, but conventions    vary here  If you use an issue tracker, put references to them at the bottom, like this:  Resolves: #123 See also: #456, #789

 

https://udacity.github.io/git-styleguide/

 

Udacity Nanodegree Style Guide

Introduction This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development. Therefore, in order to reduce the

udacity.github.io

 


 

Semantic Commit Messages

 

- 메시지의 구조

type: body 

feat: add hat wobble

^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

 

작성 방법

 

- 유형 (Type) : 

  • chore: add Oyster build script
  • docs: explain hat wobble
  • feat: add beta sequence
  • fix: remove broken confirmation message
  • refactor: share logic between 4d3d3d3 and flarhgunnstow
  • style: convert tabs to spaces 
  • test: ensure Tayne retains clothing 

- 내용 (Body):

현재 시제로 요약하여 작성 

 

https://seesparkbox.com/foundry/semantic_commit_messages

 

Semantic Commit Messages

See how a minor change to your Git commit message style can make you a better programmer.

seesparkbox.com

 

 


 

이 외에 Semantic Commit Messages 가 참고한 Karma의 Commit Message Convention 도 참고하시면 좋을 것 같습니다.

http://karma-runner.github.io/0.10/dev/git-commit-msg.html

 

Karma - Git Commit Msg

The reasons for these conventions: automatic generating of the changelog simple navigation through git history (eg. ignoring style changes) Format of the commit message: ( ): Message subject (first line) First line cannot be longer than 70 characters, seco

karma-runner.github.io

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

'Programming > Tips' 카테고리의 다른 글

Git Commit Message Convention ( 깃 커밋 메세지 컨벤션)  (0) 2020.08.05
Udemy Course 다운로드 하기  (0) 2019.10.04

0개의 댓글