Source: https://www.conventionalcommits.org/en/v1.0.0/
A specification for adding human and machine readable meaning to commit messages
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)]Types
feat
Introduces a new feature
fix
Patches a bug in the codebase
refactor
A code change that neither fixes a bug nor adds a feature
build
Changes that affect the build system or external dependencies
chore
Involves maintenance tasks or changes that don’t directly modify the source code or test files
ci
Changes in CI configuration files and scripts
docs
Documentation only changes
style
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
perf
A code change that improves performance
test
Adding missing tests or correcting existing tests
Footers
BREAKING CHANGE
This footer should be added when a breaking change is introduced, following the next format:
BREAKING CHANGE: <description>