The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.
The commit message should be structured as follows:
<type>[optional scope]: <description>
[optional body]
[optional footer]
The commit contains the following structural elements, to communicate intent to the consumers of your library:
- 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 the text
BREAKING CHANGE:at the beginning of its optional body or footer section introduces a breaking API change (correlating withMAJORin semantic versioning). A BREAKING CHANGE can be part of commits of any type. - Others: commit types other than
fix:andfeat:are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommendschore:,docs:,style:,refactor:,perf:,test:, and others.
We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug.
Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).
A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
chore!: drop Node 6 from testing matrix
BREAKING CHANGE: dropping Node 6 which hits end of life in April
docs: correct spelling of CHANGELOG
feat(lang): add polish language
fix: correct minor typos in code
see the issue for details on the typos fixed
closes issue #12
https://www.conventionalcommits.org/en/v1.0.0-beta.4/
Automatically generating CHANGELOGs
Automatically determining a semantic version bump (based on the types of commits landed)
Communicating the nature of changes to teammates, the public, and other stakeholders
Triggering build and publish processes
Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history
semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.
https://github.com/semantic-release/semantic-release/blob/master/docs/extending/plugins-list.md
https://github.com/semantic-release/commit-analyzer
https://github.com/semantic-release/git
https://github.com/semantic-release/changelog
https://github.com/semantic-release/release-notes-generator
https://github.com/semantic-release/exec
https://github.com/semantic-release/npm
https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format
https://github.com/nodejs/node/commits/master https://github.com/angular/angular/commits/master
https://nodejs.org/en/blog/release/v16.1.0/ https://github.com/semantic-release/semantic-release https://docs.npmjs.com/about-semantic-versioning
https://docs.npmjs.com/about-semantic-versioning
https://github.com/conventional-changelog/conventional-changelog https://github.com/aevea/commitsar https://github.com/conventional-changelog/standard-version https://github.com/talos-systems/conform
https://dev.azure.com/lucianmachado/talkcc/_workitems/edit/1/