The Lost Art of Commit Messages
seyhan.me
The Lost Art of Commit Messages
1–10 of 61 posts
Re: The Lost Art of Commit Messages
#2I wouldn't say its a lost art... we do this at our company
Re: The Lost Art of Commit Messages
#3How is distilling a novel down to a short description and 2 points any better? This format is too limiting.
Re: The Lost Art of Commit Messages
#4Example commits of something I worked on a few days back:
$ git l feature/character-selection
c54825f 3 days ago Robert Schaap (feature/character-selection) Simplify color picker, fetch current color
d512569 3 days ago Robert Schaap Fix recolor for female, clean up files
6d05ce4 3 days ago Robert Schaap Add color picker to change shirt color
441180b 3 days ago Robert Schaap Show male in editor
17045dc 3 days ago Robert Schaap Remove old character
95772ff 3 days ago Robert Schaap Add characters
Then when I squash merged it I ended up with this commit message: $ git show HEAD~1
commit be50e0d701d565cebdf4f29e0c9d8030a1a8faf7
Author: Robert Schaap
Date: Mon Mar 24 21:29:20 2025 +0100
Character selection (#14)
* Add characters
* Remove old character
* Show male in editor
* Add color picker to change shirt color
* Fix recolor for female, clean up files
* Simplify color picker, fetch current colorRe: The Lost Art of Commit Messages
#5From the article: "- adjust timeout settings to prevent crashes". Include the details of why the timeout setting lead to crashes; what were the inputs and the cases that caused this.
This lets us decide whether the fix stays or goes the next time there is an issue in the same piece of code, or your commit broke something unrelated - the person fixing it needs to know _why_ you changed the code.
Re: The Lost Art of Commit Messages
#6Why do we care about commit messages? I only read them when rebasing.
Re: The Lost Art of Commit Messages
#7Each commit becomes one "unit of review", and the commit message can be reviewed just like the code changes.
Re: The Lost Art of Commit Messages
#8There are times when I make a one-line change and write a paragraph or two explaining why it had to be done. But these kinds of things often drown in the noise of a dozen other changes. If that one was important enough, I will reference it in an ongoing discussion or documentation, or at least include "read below:" on the first line.
I usually see people include a more elaborate commentary with the pull request. If the changeset is good but the series of individual commits is a bit messy, just merge by squashing.
(Also: this comment is meta.)
Re: The Lost Art of Commit Messages
#9Re: The Lost Art of Commit Messages
#10You get some of this for free if you create branches and squash merge them when finished. Without needing to think much about commit message, just a few words per commit is enough. This is good enough for me and I don't need to waste any time thinking about it. Example commits of something I worked on a few days back: $ git l feature/character-selection c54825f 3 days ago Robert Schaap (feature/character-selection) S…
> Add characters
I can probably tell from the code that that's what's happening. But what requirements drove these particular characters?
> Remove old character
What makes it old? How would I recognise an old character in the future?
> Show male in editor
Why did male not show before? Was there a bug or a partially implemented feature?
> Fix recolor for female, clean up files
What does it mean to "fix recolor"? And even worse, what is "clean up files"? What requirements drove this file cleaning? Why were the files unclean in the first place?
etc. Commit messages in the style of "fix X" or "add Y" or "remove Z" or "nondescript action on W" are the bane of my existence. They seem so meaningful but they don't tell me anything when I'm trying to trace why a particular bug was introduced – or whether it's even a bug in the first place.