Which Conventional Commit Type Should I Use?
Choose the right Conventional Commit type for feat, fix, docs, refactor, perf, test, build, ci, chore, and revert commits.
Direct answer
Choose the Conventional Commit type from the user-visible effect first, then the files changed. Use feat when the user gets a new capability, fix when broken behavior is restored, docs for documentation-only changes, refactor when behavior stays the same, perf when the same behavior is faster, test for test-only changes, ci for workflow changes, build for dependencies or build tooling, chore for maintenance, and revert when undoing a prior commit.
Open Conventional Commit GeneratorWhen to use this
- You know what changed but are unsure whether it is feat, fix, chore, refactor, or docs.
- The files changed do not match the effect, such as a bug fix inside refactored code.
- You want commitlint and semantic-release to interpret the change correctly.
Steps
- Describe what changed in plain English.
- Name the user-visible or release-visible effect.
- Pick the type from that effect instead of the folder changed.
- Add a short lowercase scope if one area is clearly affected.
- Generate the final subject and review it before committing.
Example
Changed the login form and AuthService so users are sent back to the page they originally requested after signing in. Added a regression test.
fix(auth): preserve redirect target after login
Common mistakes
- Do not use refactor for a bug fix just because implementation files were reorganized.
- Do not use chore for user-facing behavior changes.
- Do not invent a type unless your commitlint config allows it.
FAQ
- Should I choose the type by file changed or behavior changed?
- Choose by behavior changed. A fix in a UI file is still fix, and a docs-only change in a source folder is still docs.
- When should I use chore?
- Use chore for maintenance that does not change runtime behavior, docs, tests, build tooling, or CI in a way covered by a more specific type.
- Is refactor a release change?
- Usually no. Refactor means the code changed internally while behavior stayed the same, so release automation normally does not publish a version from it.
Related Conventional Commit guides
Fix a Commitlint Conventional Commit Failure
Rewrite failed commitlint subjects into valid Conventional Commit messages with the right type, scope, subject, and breaking-change footer.
Semantic Release Conventional Commit Version Bump
Use Conventional Commits to signal patch, minor, and major releases for semantic-release, release-please, changesets, and similar tooling.
AI Coding Session Commit Message Generator
Turn a Claude Code, Codex, Cursor, Copilot, or Windsurf coding session summary into one clean Conventional Commit message.