This project uses standard-version, which depends on [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) rules, for versions and change logs management.
In this case your commit message should be structured as follows:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Common commit structural elements are:
-
fix: a commit of the type
fixpatches a bug in your codebase (this correlates withPATCHin semantic versioning). -
feat: a commit of the type
featintroduces a new feature to the codebase (this correlates withMINORin semantic versioning). -
BREAKING CHANGE: a commit that has a footer
BREAKING CHANGE:, or appends a!after the type/scope, introduces a breaking API change (correlating withMAJORin semantic versioning). A BREAKING CHANGE can be part of commits of anytype. -
typesother thanfix:andfeat:are allowed, for example[@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)(based on the the Angular convention) recommendsbuild:,chore:,ci:,docs:,style:,refactor:,perf:,test:, and others. -
footersother thanBREAKING CHANGE: <description>may be provided and follow a convention similar to git trailer format.
Here is some commit message examples.