51 lines | 1.6 KB
Raw

Git commit conventions — Claude Code rules

Format

<type>(<scope>): <subject>

<body>

<footer>
  • type: feat / fix / refactor / perf / test / docs / chore / ci / build / revert.
  • scope: a short noun for the area touched (auth, cli, db). Optional but encouraged.
  • subject: imperative mood, no trailing period, ≤ 72 chars.
  • body: explain the why, not the what (the diff already shows the what). Wrap at 72.
  • footer: BREAKING CHANGE: … if applicable, plus issue refs (Closes #123).

Examples

feat(auth): require GitHub email for sign-in

The previous implementation accepted users without a verified primary
email, which prevented us from sending invoices. New sign-ins now fail
fast with a friendly error directing the user to verify on GitHub.

Closes #142

fix(cli): preserve trailing newline when reading rulepack.json

JSON.parse strips the trailing newline; the subsequent write added one
back, causing every git status to show the file as dirty. Read raw and
re-emit verbatim.

House rules

  • One logical change per commit. Don't bundle a refactor with a feature.
  • Commit before context switching. WIP commits get squashed on merge.
  • BREAKING CHANGE in the footer triggers a major bump in semver tools (changesets / semantic-release). Use it deliberately.
  • Never amend a commit you've already pushed to a shared branch.

What not to do

  • ❌ "Update files" / "WIP" / "fix" as the only commit message on a shared branch.
  • ❌ Bundling formatter changes with feature commits — split them.
  • ❌ Force-pushing main.