I thought conventionalcommits.org was very well known.
I made my company use it and now it’s so much easier to navigate git history. We also get automatic, humanly readable changelogs for free.
git commit -am "no u"A while ago, I wrote a tool to generate change logs from commit messages. It grabs all commits from a tag to the previous tag, and collates them into a Keep A Changelog format.
An unintended consequence is this is that my commit messages are in keepachangelog format; the tool just groups messages by type and adds the version and date decoration, and then inserts the text at the right place in the file.
It’s fantastic. Because I know the commit messages will end up in the changelog, it encourages me to describe the commits in terms of:
Adds blah blah Changes blah blah Fixes blah blah
Anything that doesn’t start with a keyword is discarded, so I can still jot notes in the commit, but by far the biggest benefit is that it’s completely broken me of the habit of reiterating the code change that I committed, and write the reason for the commit in descriptive language.
Having a little reinforcement such as tooling can do wonders for building good habits.
One of the things I hate about merge-based Git workflows is git makes a default
Merge 123234234 from user/dave/fsdfmessage which:a) Is shit - it contains zero useful information (what’s in the change??) and contains information you explicitly don’t care about (the temporary branch name the author happened to use). a) Makes people think they are supposed to use that message.
It would probably be better if the default message was blank. But also squash & rebase is generally better anyway and it avoids this problem entirely.
TIL I write better commit messages in my hobby projects than some Linux maintainers
