Skip to main content

Conventional Commits

Conventional commits are a method of writing git commit messages in a standardized format that also enables automatic determination of the next release type in a semantic versioning system.

Conventional commits consist of a few primary elements:

  • type: The type of the commit. The type can be one of a pre-configured number of elements, including (in this project) feat for features, fix for bug fixes, docs for documentation updates, chore for meta-stuff in the repo (not updating the packages), and some more.
  • scope (optional): The scope of the change, for example, the package name or something like ci
  • description: a one-liner description of the type (feature, bug fix, or something else)
  • body (optional): more detailed descriptions
  • footer (optional): key-value-pairs of extra meta information, for example, fixed GitHub issues

All in all, the structure looks something like this:

<type>[(optional scope)][!]: <description>

[optional body]

[optional footers]


Since this doesn't look too intuitive, here are a few examples of actual commit messages:

Example: A commit message for a bug fix introducing breaking changes
fix!: Fixed parameter conversion in `updateParents()`

Before, it automatically converted strings to numbers in such a
way that non-number inputs also got allowed. This is now changed.

Fixes: #8
BREAKING CHANGE: Non-number inputs no lead to `updateParents()` to
Example: A commit message for a feature in the package pkg-1
feat(pkg-1): Constructor for JSON parameter

added constructor for a JSON string as the single parameter
to `PackageOneClass`

Fixes: #22
Co-Authored-By: Pablo Klaschka <[email protected]>

See also

Commit Types Reference »../references/conventional-commit-typesConventional Commits Website/Specification »