1 min read

커밋 가이드의 규칙

잘된 커밋가이드는 무엇일까?

커밋 메세지는 개인의 나타나 있다구 생각한다. 그러다보니 커밋 메세지에서는 작업한 Job에대한 내용이 자기만 볼수있는 경우가 많고 제 3자가 커밋메세지를 봤을때 무슨 내용인지 모르는 경우가 자주생긴다.

결국 코드를 보는 최악의 경우가 발생한다.

나는 이를 줄이기 위해 여러가지를 찾았고 그중 하나가 바로 아래이다.

Example

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

More Examples:

  • feat: (new feature for the user, not a new feature for build script)
  • fix: (bug fix for the user, not a fix to a build script)
  • docs: (changes to the documentation)
  • style: (formatting, missing semi colons, etc; no production code change)
  • refactor: (refactoring production code, eg. renaming a variable)
  • test: (adding missing tests, refactoring tests; no production code change)
  • chore: (updating grunt tasks etc; no production code change)

출처 : https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

제가 주로 사용하고 있는 커밋가이드는 위와 같다. 또한 팀에서 커밋가이드가 엾을경우에는 위와 같이 설정한다.

이 커밋가이드를 사용시 주의할점이있다면 설명은 꼭 한글로 쓰자는 것이다.