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 five primary elements:

  • type: The kind 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 repository (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]

Examples

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

Example: A commit message for a bug fix introducing breaking changes
fix!: Fix 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
throw
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 <contact@pabloklaschka.de>

See also

Commit Types Reference »/internal/references/conventional-commit-typesConventional Commits Website/Specification »https://www.conventionalcommits.org/en/v1.0.0/