Git Commit Messages That Help Reviewers (and AI) Understand You

A bad commit message — "fix stuff", "wip", "asdf" — costs everyone who touches the code later. A good commit message turns a future bisect from a headache into a ten-second look. Here is the format we use and why each part matters.

The 50/72 rule

First line is a summary, capped at 50 characters. Then a blank line. Then a body wrapped at 72 characters explaining the WHY. This format renders correctly in git log, GitHub PR views, and editor summaries.

Lead with the why, not the what

Don't write "Update auth middleware" — the diff already shows that. Write "Reject expired sessions earlier to drop p99 latency". The reviewer knows what changed; they want to know why.

Reference the problem, not the file

"Fix bug in users.ts" ages badly the moment users.ts gets renamed or split. "Fix duplicate email check on signup" survives any refactor.

One concept per commit

Every commit should be revertable in isolation. If you find yourself writing "and" in your subject line, you have two commits, not one.

Why AI reviewers care

When you paste a diff or PR into an AI code reviewer, the commit message is part of the input. A clear "why" lets the AI judge whether your code matches your intent. A message like "wip fix" gives the AI nothing to work with and the review becomes generic.

A template that always works

<verb> <subject> to <outcome>

Why this matters:
- Bullet 1
- Bullet 2

Closes: #1234

Examples: "Cache user settings to drop dashboard load by 400ms". "Reject malformed JSON early to surface real errors". "Move error logger to /lib/logger to share across routes".

Adopt this for two weeks and your future reviews — human or AI — get measurably faster.