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)
fixfor bug fixes,
docsfor documentation updates,
chorefor 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
- 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>
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.
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
Co-Authored-By: Pablo Klaschka <firstname.lastname@example.org>