[깃 | Git] Udacity Git Commit Message Style Guide - 깃 커밋 메시지 일관성있게 쓰기 (스타일 가이드)
study/others

[깃 | Git] Udacity Git Commit Message Style Guide - 깃 커밋 메시지 일관성있게 쓰기 (스타일 가이드)

커밋 메시지가 보기 좋아야 (일관성있고 체계적으로 작성해야) 나중에 다시 보았을 때 어떤 기능을 추가했는지, 어떤 버그를 고쳤는지 알기 편하다.

최근에 코드를 체계적으로 작성하기 위해서 Java, Python의 Style Guide를 참고했었는데, 커밋 메시지에도 가이드라인이 있다!

오늘은 그 중에서 유다시티의 커밋메시지 스타일가이드를 소개한다. 

우아한테크코스 개발팀들의 커밋을 보면 참 예쁘다.. 나도 내년에는 해야지

- Commit Message Structure (커밋 메시지 구조)

커밋 메시지는 빈 줄로 나뉘어진 세 가지 파트로 구성된다. title, body(optional), footer(optional)

레이아웃은 아래와 같다.

type: Subject

body

footer

 

- The Type (커밋 타입)

커밋 타입은 제목(title)에 해당하며, 아래 중 하나이다.

  • feat: 새로운 기능
  • fix: 버그 픽스
  • docs: documentation의 변경
  • style: 코드 포매팅, 세미클론 누락 등. 코드에 변경사항은 없어야 한다. (no code change)
  • refactor: 코드 리팩토링
  • test: 테스트 추가, 테스트 리팩토링. 테스트가 아닌 코드에 변경사항은 없어야 한다. (no production code change)
  • chore: 빌드 업데이트, 패키지매니저 설정 변경 등. 실제 코드에 변경사항은 없어야 한다. (no production code change)

- The Subject (주제)

주제는 제목(title)에 해당한다. 50자보다 길어서는 안 되며, 시작은 대문자여야 한다. 또 마침표를 붙이지 않는다.

명령조로 작성하며, 과거시제를 사용하지 않는다. changed, changes가 아닌 change로 작성한다.

- The Body (본문) 

모든 커밋이 본문을 필요할 정도로 복잡하지 않으므로, 필요한 경우에만 약간의 설명과 맥락을 덧붙인다.

본문에는 어떻게(how)를 설명하지 말고, 무엇(what)과 (why)를 작성한다.

(Use the body to explain the what and why of a commit, not the how.)

본문을 작성할 때에는 제목과 빈 줄로 구분하고, 본문의 한 줄이 72자를 넘지 않도록 한다.

추가적인 내용이 필요하면 빈 줄로 단락을 구분해도 된다.

- The Footer (꼬리말)

issue tracker ID를 참조할 때, 필요한 경우에만 사용한다.

- 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

아직 깃을 쓰는 법을 제대로 알지는 못한다.

나도 이제야 브랜치 열어서 커밋-푸시-머지정도의 흐름만 알고있지... 기획부터 시작하는 프로젝트를 하지 않아서 그런 것 같다.

그럼에도 Style Guide를 지켜가면서 커밋하는 건 중요한 것 같다. 지금까지 지켜본 적도 없지만.. 블로그에 올리는 겸 해서 이제부터 올리는 데 집중해야지.

규칙을 지켜가면서 올리면 확실히 1기능-1커밋이 가능할지도? 그러기 위해서는 기능별 기획도 잘 해야겠지. 이게 제일 중요한 것 같다.

글 쓰고 내 커밋을 보니 처참하다..

아래는 원문이다.

 

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