git-conventionslisted

# Git conventions Commit messages are read in `git log --oneline`, in blame, and in release notes. Optimize for that, not for explaining yourself. A message that only reads well on the GitHub commit page is the wrong shape. ## 1. Never commit unasked Finish the work, run the build, report the result, then ask. No commit and no push happens without an explicit yes. Never add a `Co-Authored-By: Claude` trailer. Commits are authored by the repo owner alone. No em dashes in the subject, body, or footers, same as everywhere else. ## 2. Commit format ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ### Types | Type | Use | SemVer | | --- | --- | --- | | `feat` | Adds a capability that did not exist | MINOR | | `fix` | Patches a bug | PATCH | | `docs` | Documentation only | | | `style` | Formatting, whitespace, no change in behavior | | | `refactor` | Neither fixes a bug nor adds a feature | | | `perf` | Makes something faster or lighter | | | `test` | Adds or corrects tests | | | `build` | Build system, bundler, or dependencies | | | `ci` | CI configuration and pipelines | | | `chore` | Maintenance with no src or test change | | | `revert` | Reverts an earlier commit | | Pick by what the change does for a consumer, not by which files moved. Renaming a variable inside a bug fix is still `fix`. Adding a dependency in order to build a feature is still `feat`. When two types genuinely apply, the change is two commits. ### Scope An option