Need AI Training/Help?CloudYeti.io/meet
MarkdownMe
Developer commit guide

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 Generator

When 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

  1. Describe what changed in plain English.
  2. Name the user-visible or release-visible effect.
  3. Pick the type from that effect instead of the folder changed.
  4. Add a short lowercase scope if one area is clearly affected.
  5. Generate the final subject and review it before committing.

Example

Change context
Changed the login form and AuthService so users are sent back to the page they originally requested after signing in. Added a regression test.
Commit message
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