The Commit Message Crisis
You’ve finally wrestled your changes into a semi-working state, you’ve staged your files. You’re one keystroke away from sending them off into version control history. You type
git commit -m “”
And then…hmm. I know, I know. I bet you’ve done it too though?
Refactor bug fix
I know that you know. Writing code is hard. Imagine there was a time in your life where you didn’t know the meaning of edge case. Many people enter this industry thinking that they’re something special, and that they’re well above the average.
The problem is when you put everyone who is above the average into the same group, everyone in that group won’t be average.
So when you’re tired, hungry, three stand-ups behind, and Slack is pinging you about a design doc nobody will read the demons will come out to play.
So when I moved a thing, renamed another thing I fixed something. I’m not sure how, but I don’t let that worry me. It made sense in the moment, and I’ve got more fixes that I need to push down the pipe now. It’s all getting dangerously close to “final_final_fix_REAL_v3” territory, but here we are.
The Invisible Legacy
Commit messages aren’t for you. They’re for future-you.
Or perhaps they’re for the unfortunate dev who joins the project two months after you rage-quit and starts reading the Git history like an archeologist unearthing a forgotten civilization built on spaghetti and poor life choices. Which might just be future-you.
Every “fix stuff” or “temp” or “this shouldn’t break” is a missed chance to document your process, your thinking, and your intent. It does rather assume you had one, but there you go.
The Wrong Kind of Honesty
Sometimes I try to be honest in my commit messages. Too honest.
“this still doesn’t work but I need to push”
“co-worker broke it, I’m just trying to unbreak it”
“hacky fix because meetings”
“I hate this code”
Git is version control, not therapy. These messages might be cathartic in the moment, but they won’t hold up under code review, or worse, during a blame operation in six months when the CTO wants to know why the payment screen crashes in production. Because it inevitably will, and will blow back to you in time.
The Industrial Complex of Commit Linting
Of course, some teams try to solve this with structure.
“feat: add button for dog adoption”
“fix: prevent crash when user has no name”
“chore: update dependencies nobody asked for”
Useful? Maybe. Robotic? Absolutely. Nothing makes you feel more like a productivity drone than shoving your creative dev work through a regex validator that rejects “fixed it” because it lacks a Jira ticket and an RFC reference.
If you’re writing prose to appease a linter, are you even human anymore? I can’t answer the question on whether you’re offering any value if you just created a prompt to solve this coding conundrum.
When In Doubt, Write Something Useful
Here’s what I do now. It’s not perfect, but it’s better than silence:
Summarize what changed in plain English.
Think about why the change was made, not just what.
Mention side effects if you suspect there’s a small fire hidden in the diff.
Try not to be passive-aggressive (unless it’s funny).
Some examples I’ve actually used (and stand by):
“Fix API call to handle null values returned from backend (yes, again)”
“Refactor signup flow to be less of a dumpster fire”
“Disable animation on startup because it made people motion sick”
Conclusion
Good commit messages won’t win you a Pulitzer, but they might save a junior dev from six hours of debugging. And honestly, that’s the nicest thing you can do in this industry.
But does that even matter?
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.
The Secret Developer believes your Git history says more about your emotional state than your codebase ever could. Seek help. Or snacks. Probably snacks.