Git commit messages

The canonical reference is Chris Beams’ How to Write a Git Commit Message (capture: clippings/cbea-ms-git-commit.md): subject line ≤50 chars, imperative mood (“Add” not “Added”), no trailing period; blank line, then body wrapped at 72 answering what/why — the diff already shows the what-visible, the message carries the why. The test: the subject completes “if applied, this commit will ___”.

Atomic commits are the precondition — a message can only be imperative-and-clear when the commit does exactly one thing:

• Git Legit habits (captured: clippings/dev-to-paulinevos-atomic-commits-will-help-you-git-legit-35i7.md): one fix/feature per commit, build green on every commit (revertability!), amend until the bug is actually fixed instead of stacking “fixed”/“broke”/“PR feedback” commits
• The commit-by-commit review those enable (from the same Git Legit set: cheat sheet clippings/dev-to-paulinevos-git-legit-cheat-sheet-2gf0.md, auto-bisect clippings/dev-to-paulinevos-fix-bugs-fast-with-regression-tests-and-auto-bisect-3khh.md)
• git-cliff (OSS) generates changelogs FROM such messages — conventional commits pay rent downstream

Reading history is the other half: the git commands to run before reading any code (capture: clippings/piechowski-io-post-git-commands-before-reading-code.md) — git log --format=format: --name-only | sort | uniq -c | sort -nr finds hotspots, churn clusters reveal where the risk lives, before opening a single file.

Related: Git recovery (rebase -i is how you fix messages) · Git hooks (commit-msg as a gate) · Golden repo