|
If you find commit messages useless, it's because you're making them useless. It seems like the workflow where you get 20 "stuff" commits in a PR is to: git commit -am "stuff", test it, see that it doesn't work, make another change, hit up then enter on the shell window, test it, and so on. If this is how you prefer to develop then I think testing first and squashing along the way might be better: - initial change, test, worked? git add <files>, git commit -m "meaningful summary\n\n- meaningful note" - small change: test, didn't work, git reset --hard - another attempt: test, worked, git add, git add <files>, git commit --amend (new meaningful note) If the steps you're taking to get to the end are meaningful or significant (maybe for a bisect in the future) then just commit with a meaningful message along the way. More generally, I think it's more common create commit messages for "me", the writer, and not for the reader. Try instead writing commit messages (comments, documentation..) for an audience who doesn't have the context you have. For example: Nathan in 7 (or 2) years time who is tracking down the reason for a change you made which he suspects is the cause of a bug he's trying to fix. |
It turns out that a coworker had discovered the --amend flag, but spelled it as -amend, and so it was interpreted as -a -m "end"