Conventional Commits
A predictable commit message style that lets tools calculate version bumps and assemble release notes.
What it is
Conventional Commits is a small grammar for commit messages: a type such as `feat` or `fix`, an optional scope, a short description, and optional body and footers. `feat(auth): add passkey login` is machine-readable without becoming unreadable. A `BREAKING CHANGE:` footer, or `!` before the colon, marks an incompatible change. The grammar is lifted from the Angular team's commit guidelines, which is why the type list looks the way it does.
Reach for it when commits feed Semantic Versioning, changelogs, or release automation. Tools such as commitlint and semantic-release can turn `fix` into a patch, `feat` into a minor, and a breaking change into a major release, while grouping the same messages into release notes.
Gotcha: the convention cannot rescue vague history. `fix: stuff` passes the grammar but tells a reader nothing, and squashed pull requests only preserve the final squash message. Agree on a short type list, enforce it where the final commit is created, and describe the user-visible change.
Ask AI for it
Set up Conventional Commits 1.0.0 for this repository. Configure @commitlint/config-conventional and Husky to validate local commit messages, then add a GitHub Actions check that validates every commit in a pull request. Allow feat, fix, docs, refactor, perf, test, build, ci, chore, and revert; require a nonempty lowercase subject; support optional scopes; and recognize both a `BREAKING CHANGE:` footer and `type!:` syntax. Configure semantic-release to map fix to patch, feat to minor, and breaking changes to major, and document examples plus the behavior for squash merges.