What are conventional commits and how do they connect to versioning?

Short answer

Conventional commits structure messages as type(scope): description — feat, fix, docs, refactor, test, chore. Types drive semantic versioning automatically: feat bumps minor, fix bumps patch, breaking changes (feat!:/BREAKING CHANGE) bump major — tools like semantic-release automate releases and changelogs from history.

Detailed explanation

Standardized messages turn commit history into machine-readable release data. Format: type(optional scope): imperative description — feat(auth): add OAuth login. Core types: feat (new capability), fix (bug), plus non-release-affecting docs/refactor/perf/test/build/chore/ci. Breaking changes signal two ways: exclamation feat!:(api): ... or a BREAKING CHANGE: footer paragraph — both trigger major bumps. The payoff chain: semantic-version tooling reads commits since last tag, computes next version (patch/minor/major), generates changelogs grouped by type, tags and publishes — semantic-release/release-please run this hands-free in CI. Benefits compound: reviewers scan type prefixes for relevance, git log --grep='fix' filters bug timelines, generated changelogs stay accurate without manual curation. Enforcement ranges from commit-msg hooks (commitlint + husky) squashing mistakes early, to squash-merge conventions where the PR title becomes the commit — making well-formed titles a team habit rather than a plugin mandate.

Common mistakes

• Mixing up which types trigger which version bumps.
• Forgetting BREAKING CHANGE footers exist alongside the ! shorthand.