#381 Conventional Commits
A specification for adding human and machine readable meaning to commit messages.
Notes
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 Semantic Versioning, 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(s)]
Where for example:
typecould be: fix, feat etcoptional scopecould be(api),(css)etc
It aligns with semantic versioning (Semantic Versioning / SemVer) by mapping commit types to version bump semantics:
- feat: new feature → MINOR bump
- fix: bug fix → PATCH bump
- BREAKING CHANGE: (or ! after type) → incompatible API change → MAJOR bump
Status?
- the idea has been adopted or at least considered by many teams
- It has spurred an ecosystem of tooling: linters (e.g., commitlint), commit message generators (e.g., commitizen), changelog generators, release-automation tools and more.
See also: LCK#380 Conventional Comments