Good Commits To Save The Day

© xkcd.com #1296

When was the last time you ran git log and scrolled a bit in your project? How was it? Did all of the messages really tell you what was changed? And could you easily determine that last commit that was in the previous customer delivery? For most of my projects I can easily admit that it’s not looking very good, pretty much like in the xkcd comic above.

Writing good commit messages takes time to learn but it might some day save a lot of effort. Here are few tips to help you on the way:

• Be consistent. Writing good commit messages only from time to time will not help in the long run, actually quite the opposite. Good idea is to include commit messages also to be part of your code review process. This way people will learn on the way by reading each others commit messages
• Spread the word. Agree in your team / with your project members what is your quality criteria for commit messages. Good idea is to agree to use Conventional Commits which already provides some useful tooling around it. Once you get hold of it, spread the word outside of your project to other teams and projects
• Force the rules. While checking the commit messages in code reviews is a good idea, you might also want to force the agreed rules. This can be done pretty easily by using git pre-commit hooks. A good example is the commitlint project