Conventional Commit Types
This document gives you a quick way to determine the correct conventional commit type for your change.
Diagram
Table
Use the most extensive type (the highest in the table below) if a commit
includes more than one commit type. Using the broadest type ensures correct
versioning. For example, if a feature, as a side-effect, also fixes a bug, it's
still a feature. If it closes an issue, please still include
Closes: #issue-number in the commit's footer to signify the fix
If a commit has breaking changes, you need to declare it using an exclamation
mark (!) before the colon (between the type and the colon (:), for example,
fix!: Hello world, or, if it exists, the scope and the colon, for example,
feat(scope)!: Hello World). With breaking changes, you should include a
BREAKING CHANGE: [description] footer describing the breaking change.
| Conventional Commit Type | Changelog entry | Minimum Version Bump | Description |
feat | Features | minor (major if breaking) | Newly implemented features |
fix | Bug Fixes | patch (major if breaking) | Bug fixes |
docs | Documentation Changes | patch | Documentation-only changes. |
chore | n/a | patch | Meta changes that don't change the actual product, but rather the build system, CI configuration, repo structure, etc. |
style | n/a | patch | Changes that only affect the code style (fixed linting issues, etc.) |
refactor | n/a | patch | Refactorings only causing internal changes not affecting the actual behavior |
perf | n/a | patch | Performance-only changes, not affecting the actual behavior |
test | n/a | patch | Added, removed or changed unit, integration or E2E tests. May not include changes to the source code. |
