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 personal take on this is that if you're doing semantic commits, then you really don't want to be doing squash merges as you will lose context. Squash merges are in general best for dealing with cleaning up a series of crap commits.
If you're following good commit practice, then every commit is atomic to your needs. I go out of my way to make sure that as I'm developing each commit is literally the barest minimum for a single modification (bug fix, feature, docs, etc). I even do my refactoring this way. I only refactor one thing at a time per commit. Yes, it makes for a lot of commits, but smaller commits are easier to code review anyway!