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:
@tobias-edwards The latter part is a real issue in practice. You can often split files to get a fix apart a feat, but it gets very annoying when you have to juggle with hunks. Punishing when not working on separate branches, but sometimes you try to get stuff done in a quick fashion (and sometimes it happens in parallel tasks, oof). I'm guilty of committing files with different changes putting them all under one message as well, we all were at some point.
So yes, committing properly is not easy, but semantic commits helped me to reduce overhead. I agree to all your points.