Invalid or Unrecognized Commit Type
What happens when you use a commit type not in the allowed list. Learn the standard Conventional Commits types and how to add custom types.
Detailed Explanation
Recognized Types
The Conventional Commits specification defines only two required types: feat (new feature) and fix (bug fix). However, the community has established a broader set of conventional types based on the Angular convention:
| Type | Purpose | Version Bump |
|---|---|---|
feat |
New feature | Minor |
fix |
Bug fix | Patch |
docs |
Documentation only | None |
style |
Formatting, whitespace | None |
refactor |
Code restructuring | None |
perf |
Performance improvement | Patch |
test |
Adding/fixing tests | None |
build |
Build system changes | None |
ci |
CI configuration | None |
chore |
Maintenance tasks | None |
revert |
Reverting a commit | Depends |
Invalid Examples
update: change user avatar size
update is not a recognized type. Depending on the change, this should be feat, fix, style, or refactor.
bugfix: resolve login timeout
bugfix is not standard — use fix instead.
Adding Custom Types
Some projects add custom types to fit their workflow. Common additions include:
wip— work in progress (often squashed before merge)hotfix— emergency production fixrelease— release preparationdeps— dependency updates
In the Conventional Commits Linter, you can add custom types in the Options panel by entering comma-separated values. These are appended to the default list.
Why Type Validation Matters
Consistent types ensure that automated tools can correctly categorize commits. A changelog generator needs to know the difference between a feature, a fix, and a documentation change. Using unrecognized types causes commits to be miscategorized or dropped from the changelog entirely.
Use Case
Type validation catches typos and non-standard types early, before they reach the repository. This is especially important in teams adopting Conventional Commits, where developers may not yet be familiar with the allowed types.