코딩하는 쨈이

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

쨈,Tools/ː GitHub

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

정쨈 2021. 1. 31. 03:59

 

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 confusion on what style students should follow during the course of their projects, we urge all students to refer to this style guide for their projects.

 

1. Commit Message Structure

A commit messages consists of three distinct parts separated by a blank line: the title, an optional body and an optional footer. The layout looks like this:

 

커밋 메세지는 세개의 다른 구조로 이루어져있으며 공백으로 이루어진 행으로 구분된다.

구조는 제목 / 본문 / 꼬리말로 구성되며 레이아웃은 다음과 같다. 

type: Subject

body

footer

타이틀은 메세지의 type과 제목을 포함한다.

 

2. Commit Message Type

The type is contained within the title and can be one of these types:

  • feat: 새로운 기능 추가 (A new features) 
  • fix: 버그 수정 (A bug fix)
  • docs: 문서 수정 (Changes to documentation)
  • style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 (Formatting, missing semi colons, etc; no code change)
  • refactor: 코드 리팩토링 (Refactoring production code)
  • test: 테스트 코드, 리팩토링 테스트 코드 추가 (Adding tests, refactoring test; no production code change)
  • chore: 빌드 업무 수정, 패키지 매니저 수정 (Updating build tasks, package manager configs, etc; no production code change)

 

3. Commit Message Subject

Subjects should be no greater than 50 characters, should begin with a capital letter and do not end with a period.

Use an imperative tone to describe what a commit does, rather than what it did.

For example, use change; not changed or changes.

  • 제목은 50자를 넘기지 않고 대문자로 작성하며 마침표를 붙이지 않는다.
  • 과거시제보다 현재시제를 사용하여 명령어로 작성한다.
    • Fixed -> Fix
    • Added -> Add
feat: Summarize changes in around 50 characters or less

 

4. The Body

Not all commits are complex enough to warrant a body, therefore it is optional and only used when a commit requires a bit of explanation and context. Use the body to explain the what and why of a commit, not the how.

When writing a body, the blank line between the title and the body is required and you should limit the length of each line to no more than 72 characters.

  • 커밋 본문 내용은 선택사항이기 때문에 모든 커밋에 본문 내용을 작성할 필요는 없다.
  • 바디 내용은 어떻게 보다 '무엇을' 그리고 '왜'에 대한 내용을 설명한다.
  • 72자를 넘기지 않고 제목과 구분하기 위해 한 칸을 띄워 작성한다.

 

5. The Footer

The footer is optional and is used to reference issue tracker IDs.

  • Footer는 선택사항이기 때문에 모든 커밋에 꼬리말을 작성할 필요는 없다.
  • Issue tracker ID를 작성할 때 사용한다.

 

6. Example Commit Message

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 consequences 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/