How do I write a good commit message?

A good commit message completes the sentence 'If applied, this commit will…' — so `Fix crash when cart is empty` rather than `fix`. It matters because commit messages are the only record of *why* a change was made, and 'why' is exactly what code cannot express. When it pays off: six months from now someone (probably you) will find a strange line, run `git blame`, and get one of two things — a message explaining that it works around a specific API bug, or the word `update`. The first saves an hour; the second means the line gets 'cleaned up' and the bug returns. The format that's near-universal: ``` Short summary in imperative mood, under ~50 chars Optional body explaining WHY this change was needed, what approach was taken, and anything non-obvious. Wrap at ~72 characters. ``` The rules worth following: 1. **Imperative mood**: 'Add', 'Fix', 'Remove', 'Refactor' — not 'Added' or 'Adding'. This matches Git's own generated messages ('Merge branch…') and reads consistently in a log. 2. **Be specific about the effect**: `Fix date parsing for timezones behind UTC` not `fix bug`. 3. **Explain why in the body when it isn't obvious.** The diff already shows what changed; nobody needs it restated. What they need is the reasoning — the constraint, the bug report, the decision you rejected and why. 4. **One logical change per commit.** A commit that fixes a bug, renames a variable and adds a feature can't be reverted, reviewed or understood cleanly. Small focused commits make `git bisect` and reverts actually usable. 5. **Reference the issue** if your team uses a tracker: `Fix empty cart crash (#412)`. Many teams use Conventional Commits — `feat:`, `fix:`, `docs:`, `refactor:`, `chore:` prefixes — which enables automatic changelogs and version bumping. Worth adopting if you contribute to open source, where it's common. On the practical side: if you commit `wip` while working, that's fine — clean it up before it becomes shared history. But the simpler fix is to commit at meaningful points rather than at random, which improves the messages automatically because there's now something specific to describe. The habit that fixes it fastest: before typing the message, ask 'what would I need to know if I found this commit in a year?' Ten extra seconds per commit, and your history turns from noise into documentation. It's also one of the first things reviewers notice about an unfamiliar contributor's pull request.