What makes a good commit message?
Quick Answer
A concise summary line (~50 chars, imperative mood — “Add retry to payment client”), a blank line, then a body explaining why the change was made and any context a future reader needs. The diff already shows what changed; the message should capture the reasoning.
A short imperative summary line — “Add retry to the payment client,” not “added retries” or “fixes” — then a blank line and a body that explains why. The diff tells you what changed; what the diff can't tell you is the reasoning, the constraint you were working around, the thing you tried first. That's what saves someone doing git blame in two years. I also follow Conventional Commits with a feat: or fix: prefix so tooling can build the changelog, and I squash the “wip” commits before merging.
- Conventional Commits —
feat:,fix:,chore:,docs:prefixes — enable automated changelogs and semver bumps. - Reference the issue (
Fixes #123). - “Fixed stuff”, “wip”, “update” are useless when someone runs
git blamein two years. - Squash the noise before merging so the permanent history reads as clean, logical steps.