Conventional Commits are a way to put extra information in your commit messages for machines to read. This has two major benefits:
- Nice changelogs can be automatically generated.
- The semver-ness of a release can be calculated, allowing automatic version bumping.
This means that if you use Conventional Commits and have fully-automated testing (no manual QA process) you can fully automate tooling releases.
Note that this is primarily useful for tools and libraries that follow a semver-ish release format,
not for services where
masteris always live, such as GitHub Flow.
I won't go into the format in too much detail, as the Conventional Commits docs do a good job of that. Instead I'll just give an overview of the categories I've found through looking at major projects that
The ones I've seen recommended are:
feat: a new feature
fix: a bug fix
refactor: a code change that neither fixes a bug nor adds a feature
docs: documentation only changes
test: adding missing tests or correcting existing tests
perf: a code change that improves performance
chore: updating grunt tasks etc; no production code change
style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
build: changes that affect the build system or dependencies (example scopes: npm, maven, )
ci: changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
revert: revert of a previous commit
Note that a breaking change is not a type, it's a flag you add with a
you add a
BREAKING CHANGE: footer to note what the breakage is.