Very early in my career, a senior developer explained me that a commit message should tell about the ‘why’ of a change. I didn’t follow his wise advice wholeheartedly. My explanations in commits were sometimes good, sometimes bad and ugly.

A couple of years ago, when working with AngularJS, I read about the AngularJS commit guidelines. It made me think about the importance of a good message. Recently I stumbled upon the Chris Beams’ article How to Write a Git Commit Message. It was a final reminder (sprinkled with a lot of examples) that I should improve my commit message habits.

As a practice, I rewrote all commit messages of Stravad, my current pet project. (If you ask what is Stravad – it stands for Strava Desktop, a batch editor for Strava activities) I pushed everything back to Gitlab. I know, git push --force is generally considered bad, but I’m alone on the project.

After that I started thinking about how to not to fall into the same sluggishness trap again. My problem was that I was trying to accomplish too many things in one atomic changeset. I knew that I had to implement only the foo feature, but I saw this ugly code over here, so I refactored it, and, oh my God, this build dependency was not required anymore (removed it), and, the build file was totally messy, so I cleaned it up, and … Finally I had too many things to describe with 50-80 characters.

My solution is simple:

before starting working on anything, think up-front about the commit message

Why are you going to modify the code? What is the expected outcome? Think of it like a motto for the upcoming work.


When I stick to the message, it helps me concentrate on the main reason of the change (new functionality, technical improvement, etc.). All improvements I detect are written down on the todo list. I stay more focused and productive.