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)
featfor features,fixfor bug fixes,docsfor documentation updates,chorefor 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]
Examples
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
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 <[email protected]>
