Conventional Commits
The type(scope): description format, commit types, and breaking change notation
Conventional Commits format
- Format:
type(scope): imperative description - Types: feat, fix, docs, style, refactor, test, chore, perf, ci, revert
- Breaking change: add
!after type —feat!— and aBREAKING CHANGE:footer - Body (optional): explain WHY, not HOW — the diff shows how
- semver: feat → MINOR bump, fix → PATCH bump, BREAKING CHANGE → MAJOR bump
Question 0 of 5
Which commit message follows the Conventional Commits format correctly?
fix(auth): login button colour incorrect in dark mode is correct. Conventional Commits format:
type(scope): description- type: one of feat, fix, docs, style, refactor, test, chore, perf, ci, revert
- scope: optional, in parentheses — the area affected: (auth), (api), (ui), (db)
- description: imperative mood, lowercase, no period at end
Which commit type should you use when adding a new feature that is visible to the end user?
feat — a new feature visible to the user. Conventional Commits types:
- feat: new feature for the user (triggers a MINOR version bump in semver)
- fix: bug fix for the user (triggers a PATCH version bump)
- docs: documentation changes only
- style: formatting, white-space — no logic change
- refactor: code restructure with no feature or bug change
- test: adding or fixing tests
- chore: maintenance — build scripts, CI, dependency updates
- perf: performance improvement
- ci: CI/CD configuration changes
A commit removes the deprecated getUserById API endpoint and is a breaking change. How should the breaking change be indicated?
feat! with BREAKING CHANGE footer is correct. Breaking change notation:
- Add
!after the type/scope:feat!orfeat(api)! - Add a
BREAKING CHANGE: descriptionfooter in the commit body - The footer must describe what broke and how to migrate
You update the project's CI pipeline YAML configuration. No application code changes. Which commit type is correct?
ci: is the correct type for CI/CD configuration changes. When to use ci vs. chore:
- ci: changes to CI/CD configuration files (GitHub Actions, GitLab CI, CircleCI, Jenkinsfile)
- chore: general maintenance — updating npm scripts, package.json metadata, build tools, dependency bumps
- build: changes that affect the build system (webpack, rollup, tsconfig)
Which commit message body correctly follows the "what + why (not how)" principle?
"Why" = functional style alignment and clarity is the correct body. Commit body guidelines:
- Subject line: imperative, what changed (50 chars)
- Body: explains WHY — the motivation, context, trade-off
- Not how: "changed array to filter()" is a how — the diff already shows that