git-commit-message

# 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 1. **Look at the changes**: run `git status --short` and `git diff --cached --stat` to confirm there is something staged. If the staging area is empty, stop and ask the user — never invent a commit message out of nothing. 2. **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 feature - `fix`: bug fix - `docs`: documentation only - `refactor`: refactor (behavior unchanged) - `test`: add or change tests - `chore`: build, dependencies, misc 3. **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". 4. **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. 5. **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 `feat` that 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) ```bash # 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): ```bash 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 as `chore` until 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.