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:
I agree with @martin-braun and would say fewer commit types lessen the cognitive load when writing commit messages.
I would also reiterate, "semantic commit messages" are not for everyone. I would go as far as saying if you're not using the type prefixes (
feat
,fix
, etc.) to help automate some other task e.g. releases, generate changelogs, etc., then I would drop them entirely because the types:chore
when the change is afix
. This problem is proliferated by larger commits which contain chores, fixes and featuresWriting good commit messages is hard. But we shouldn't overcomplicate it!