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:
My point was anyone can put an argument for any kind of casing with the right abstraction, whether it be correct grammar, enums, object keys, etc.
This also applies to the origin argument:
Which is arguably the most compelling argument for capitalisation, but I still wouldn't read into this too much because the commit syntax on Linux is very loose, and so Linus Torvalds hasn't seemed to think about commit capitalisation as much as you :) e.g.
https://github.com/torvalds/linux/commits/master?after=f339c2597ebb00e738f2b6328c14804ed19f5d57+104&branch=master&qualified_name=refs%2Fheads%2Fmaster
I maintain: