Git Commit Message Generation
Generate a commit message from the actual staged changes (git diff --cached). The message must let a reader know "what changed and why" without opening the diff.
Workflow
- Look at the changes: run
git status --shortandgit diff --cached --statto confirm there is something staged. If the staging area is empty, stop and ask the user — never invent a commit message out of nothing. - Pick a type: choose exactly one type prefix based on the changes (if one commit mixes types, ask the user to split it):
feat: new featurefix: bug fixdocs: documentation onlyrefactor: refactor (behavior unchanged)test: add or change testschore: build, dependencies, misc
- Write the subject: format
type: English imperative phrase, ≤50 characters. Start with a verb: "Add…", "Fix…", "Remove…", "Unify…". Ban empty subjects like "update code", "some changes", "fix bug". - Write the body (optional but recommended): 1–3 lines explaining why, not a play-by-play of how. Bug fixes must state the trigger conditions; features should describe the user-visible change.
- Output: give a ready-to-run command, not bare text the user has to assemble.
Rules
- The subject is for skimmers; the body is for future-you in three months. Keep the two jobs separate.
- A change mixing a feature and a refactor should become two commits, not one
featthat papers over the mess. - No meta-commentary in the message ("generated by AI", etc.) — the message is about the change, nothing else.
Minimal example (runnable)
# 1. Look at the changes first
git status --short
git diff --cached --stat
# 2. Suppose the change: added CAPTCHA verification to the login endpoint
# Generated commit:
git commit -m "feat: add CAPTCHA verification to login endpoint" -m "Blocks automated credential stuffing; CAPTCHA valid 5 minutes, account locks 10 minutes after 3 failures."
Another example (bug fixes must state trigger conditions):
git commit -m "fix: keep order-list filters across pagination" -m "Trigger: filter first, then turn the page. Cause: page turns dropped the query params."
Anti-patterns
- ❌ Writing a message for an empty staging area: no
git diff --cached, no commit message. - ❌ Catch-all
chore: labeling every feat and fix aschoreuntil the type system means nothing. - ❌ Novel-length subjects:
feat: add a really useful feature that greatly improves the user experience— the subject says what, leave praise to the user. - ❌ Body as implementation log: "first changed line 20 of a.py, then b.py…" — the diff already shows that; the body explains why.