Conventional Commits

Are used to have a human and machine readable structure and uniform way of doing commits. It helps your colleagues to easier and faster comprehend what you have done. In addition to that - because of the structure - it is possible to automatically create changelogs and version your software semantically Semantic Versioning

Structure of your commit message

<type>[optional scope]:<description>
[optional body]
[optional footer]

Types

Type
feat	Features	A new feature
fix	Bug Fixes	A bug fix
docs	Documentation	Documentation only changes
style	Styles	Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons, etc.)
refactor	Code refactoring	A code change that neither fixes a bug nor adds a feature
perf	Performance Improvements	A code change that improves performance
test	Tests	Adding missing tests or correcting/enhancing existing tests
build	Builds	Changes that affect the build system or external dependencies
ci	Continuous Integration	Changes on CI configuration
chore	Chores	Other changes that do not modify src or test files (.gitignore, etc.)
revert	Reverts	Reverts a previous commit

Specification

1. Commits MUST be prefixed with a type, which consists of a verb, feat, fix, etc., followed by a colon and a space

2. The type feat MUST be used when a commit adds a new feature to your application.

3. The type fix MUST be used when a commit represents a bug fix for your application.

4. An options scope MAY be provided after a type. A scope is phrase describing a section of the codebase enclosed in parenthesis, e.g., fix(parser):

5. A description MUST immediately follow the type/scope prefix. The description is a short description of the pull request, e.g., fix: array parsing issue when multible spaces were contained in string

6. A longer commit body MAY be provided after the short description. The body MUST begin with one blank line after the description.

7. A footer MAY be provided one blank line after the body. The footer SHOULD contain additional meta-information about the pull-request (such as issues it fixes, e.g., ```fixes #123````)*

8. Breaking Changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase letters BREAKING CHANGE, followed by a colon and a space.

9. A description MUST be provided after the BREAKING CHANGE: , describing what has changed about the API, e.g., BREAKING CHANGE: environment variable now take precedence over config files

10. Types other that feat and fix MAY be used in your commit messages.

Sources

Conventional Commits (opens new window)