See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope>
is optional
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)
References:
@weiying-chen Let's have a debate, shall we? :)
I only capitalize comment blocks, because they reflect a paragraph containing sentences, I do not capitalize short summaries, i.e.
My rule of thumb for comments: If it has a dot, capitalize. Do not add dots on single line comments. 2 sentences deserve a block!
For me, commit messages are short summaries and not sentences, thus I strive to keep them lowercase. (Forgot to mention "I" is an exception as well, obviously)
Contrary to this statement, the body of the commit message (if there is one) should be capitalized, here is what I mean:
Grammar rules in other places than the US, btw. The capitalization after
:
is possible in the US, while it's mandatory in British, thus, if you are formal, you capitalize after:
to be inclusive as much as possible.In regards of "Initial commit" (which is also GitHub's suggestion), I would disagree with applying their example to this discussion, since they don't even have semantic commit messages in their mind. With semantic commits it should be
chore: initial commit
, if you ask me, since the first commit just uploads code that has been changed multiple times prior. Only from the 2nd commit on changes are documented and part of the commit message, sochore
for the first commit feels right to me.Just because there are counter examples in different areas by bigger companies doesn't mean they are the right source for specific guidelines such as semantic commits that further abstract from git (not even from them themselves).
Finally, all this is nitpicking. I would argue when it comes to collaboration, it's better to be consistent, although I have screwed up so many commit messages by this stage that this is not about perfection for me personally anyways. In a perfect world you find the best practice for you and your team and stick to them for a clean history.
Subjectively, I still think my suggestion is still better, because committing is just faster and it reads very well without unnecessary distractions and less failure potential (i.e. forgot to capitalize). My 2 cents.