intermediate

Conventional commits

Use structured commit messages to drive changelogs, version automation, and searchable project history.

Conventional Commits structure messages as `type(scope): description` with optional breaking footer `BREAKING CHANGE:`. Tools parse history to suggest versions and generate changelogs.

| Type | Typical semver signal | |------|----------------------| | `feat` | minor | | `fix` | patch | | `feat!` or breaking footer | major |

					feat(auth): add OAuth callback route

fix(ui): prevent double submit on checkout

feat(api)!: remove legacy /v1 users endpoint

BREAKING CHANGE: /v1/users removed; migrate to /v2/users

Squash-merge repos must ensure the final squash message retains the type and breaking markers release tooling reads.

On interviews: automation benefits, scope conventions, when ceremony hurts small teams, and coordination with Changesets.

Common pitfalls: vague `chore` messages hiding user impact; squash titles losing structure; treating commit format as substitute for good review.

The trade-off is machine-readable history versus contributor friction.

Checklist:

Use meaningful type and scope.
Mark breaking changes explicitly.
Align squash messages with automation.
Keep commits honest about user impact.