Commit Scope and Types
Choosing the right scope, when to omit it, revert format, and CHANGELOG-triggering types
Scope and type guidelines
- Scope — the module or layer affected: (auth), (api), (ui), (db), (infra)
- Omit scope for cross-cutting changes affecting multiple modules
- style = formatting only; refactor = restructure with no behaviour change
- revert: format — subject is the original commit subject; body says "This reverts commit SHA."
- feat and fix trigger CHANGELOG entries; chore/style/refactor/test do not
Question 0 of 5
Your team defines these scopes: auth, api, ui, db, infra. You add a new database migration file. Which scope is correct?
feat(db): — the change affects the database layer. Choosing the right scope:
- Scope should match the layer or module affected — not the file type
- A migration file lives in
db/conceptually, so(db)is correct - The type
featis appropriate if the index is a new addition (not a fix) - The description "for login performance" explains WHY, making the commit self-documenting
When is it appropriate to omit the scope entirely from a commit message?
Cross-cutting changes that don't fit one scope cleanly. When to omit scope:
- A change to global configuration affecting every module:
chore: update Node.js to v20 - A refactor spanning multiple layers:
refactor: rename userId to user_id throughout - A release commit:
chore: release v2.0.0
git log --oneline | grep "(auth)" to debug an auth issue only works if auth changes are scoped.You need to revert a commit that introduced a breaking bug. Which commit message format is correct?
revert: [original subject] is the Conventional Commits format for reverts. Revert commit format:
Body:
You can add context: "Reverted due to performance regression in prod. See issue #123."
- Type:
revert - Subject: the original commit's subject line
- Body: "This reverts commit <SHA>." — Git generates this automatically with
git revert
revert: feat(auth): add OAuth2 loginBody:
This reverts commit abc1234.You can add context: "Reverted due to performance regression in prod. See issue #123."
A team debates whether to use style or refactor for a commit that reformats 200 files with Prettier. Which is correct?
style — formatting-only changes with no logic or behaviour change. Type distinctions:
- style: whitespace, formatting, missing semicolons, Prettier/ESLint autofix — no logic change
- refactor: restructuring code (extracting functions, renaming variables, moving files) — behaviour unchanged but logic is reorganised
- chore: maintenance tasks — updating npm scripts, CI config, dependency bumps — not application code
Your team wants to use commit types to automatically generate a CHANGELOG. Which pair of commit types will trigger entries in the CHANGELOG?
feat and fix — these are the user-visible changes that appear in CHANGELOGs. How standard-version / semantic-release categorises commits:
- feat → "Features" section in CHANGELOG → MINOR semver bump
- fix → "Bug Fixes" section in CHANGELOG → PATCH semver bump
- BREAKING CHANGE → "Breaking Changes" section → MAJOR semver bump
- docs, style, refactor, test, chore, ci → do NOT appear in CHANGELOG by default (internal changes)