본문 바로가기

DevOps/Git

<Git> 커밋 메시지 컨벤션 : 유다시티

1. 소개

 - 지난 장에서 간단한 깃 커밋 컨벤션에 대해서 알아보았다. 이번 장에서는 가장 흔히 쓰이는 커밋 메시지 스타일인 유다시티의 스타일을 알아보자. 유다시티는 대규모 온라인 코스를 제공하는 교육기관이다. 유다시티는 이상적인 커밋 메시지에 대해 혼란을 겪는 학생들을 위해서 Git Commit Message Style Guide를 제공하고 있다.

 

type: Subject

body

footer

 

 - 구조는 위와 같다. 지난 장에서 본 컨벤션과 다른 점은 제목에서 type을 명시하고 :(콜론)으로 구분한다는 것이다.

 

2. 구성

* 타입

 - 유다시티에서는 타입을 다음 7개중 하나로 쓸 것을 권장하고 있다.

 

 - feat : 새로운 기능과 관련된 것을 의미한다.

 - fix : 오류와 같은 것을 수정했을 때 사용한다.

 - docs : 문서와 관련하여 수정한 부분이 있을 때 사용한다.

 - style : 코드의 변화와 관련없는 포맷이나 세미콜론을 놓친 것과 같은 부분들을 의미한다.

 - refactor : 코드의 리팩토링을 의미한다.

 - test : test를 추가하거나 수정했을 때를 의미한다.

 - chore : build와 관련된 부분, 패키지 매니저 설정 등 여러가지 production code와 무관한 부분 들을 의미한다. 말 그대로 자질구레한 일들이다.

 

* 제목

 - 지난 장과 마찬가지로 대문자로 시작하는 명령형 문장이다.

 

 - 50자를 넘지 않도록 주의하자.

 

* 본문

 - 무엇을, 왜 와 같은 설명들을 작성한다.

 

 - 지난 장에서 설명했던 대로 72자가 넘어가면 문단을 나누는 것이 좋다.

 

* 푸터

 - isuue tracker id를 작성할 때 사용한다.

 

 - 어떤 이슈와 관련된 부분인지, 참고할 다른 이슈는 어떤 것이 있는지 작성할 수 있겠다.

 

3. 예시

* 메시지

 - 아래는 유다시티에서 제공하는 예시이다.

 

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

 

 - 타입은 소문자로 명시하고, 나머지는 기존에 했던 방식과 동일하다.

 

* 템플릿

 - 위의 내용들을 참고하여 만든 필자의 템플릿이다.

 

 

 - 템플릿을 만들어 git commit 때마다 편하게 내용을 확인할 수 있다.

 

 - 필자의 경우 완전히 컨벤션을 따르지는 않았다. 7개의 타입으로는 나타내기 어려운 것들이 있어서 3가지를 추가하였다. 아직 지난 장의 커밋 메시지 스타일과 혼용하여 사용하고 있지만 점차 이 컨벤션으로 변경하려 한다. 아직 완전히 바꾸지 않은 이유는 깃에서 자동으로 작성되는 Merge와 같은 메시지와의 통일성 때문이다.

 

 - 템플릿을 만드는 방법은 이 링크를 참고바란다.

 


 

참고

 

 

 

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

 

 

Git - 커밋 메시지 컨벤션

02_commit_message_rule.md Git - Commit Message Convention 커밋 메시지를 작성할 때는 원칙을 정하고 일관성 있게 작성해야 한다. 아래는 유다시티의 커밋 메시지 스타일 가이드를 참조한 내용이다. 1. Commit..

doublesprogramming.tistory.com