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.
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:
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.