Despite every guide I've ever read recommending excellent commit practices (https://dev.to/chrissiemhrk/git-commit-message-5e21 is just one example), I have noticed that almost every single commit message I encounter on any project I've worked on (admittedly, I've only ever worked on for-profit software teams) is usually only a single line summary of what was done (which is pretty easy to see just from looking at the code diff) and nary a reason why in sight.
I don't understand this -- at all. It tends to make the commit message itself almost next to useless. I get that typically these commit messages include a reference to a ticket which hopefully contains more context, but that context is usually high-level and frankly often contains little more than "fixed" or "updated" so it's not that useful either. Plus, every dev knows that the ticket system used today will one day be replaced with another, and probably with a loss of all that context. Commit messages, on the other hand, are eternal.
What makes this even more perplexing to me is that commit messages are one area where we could be as verbose as we want. The only ones who will look at it are devs and dev managers, and so we can dive deep into the technical details and considerations that warranted the change that was made. At the very least, a commit message indicating why helps when, several months down the road, during a Planning or Refinement meeting, management inevitably asks why a change was made -- and inevitably no one remembers anymore.
Are we devs really too lazy? Or is it that we have a perceived idea that management doesn't want us spending too much time on any task other than mindlessly churning out code?
Top comments (0)