Conventional Commit

Conventional CommitsConventional Commits

About

Create pattern in the Commit messages to give meaning that is understandable for humans and machines.

A way to do this is using Conventional Commits, a specification convention, following specific rules and patterns when creating commit messages.

In VSCode you may use an Extension "Conventional commits".

You can use commitizen command line utility to create commits in Conventional Commit.

Commit Message

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

<type>

Conventional Commits specify two base types: feat and fix.

• feat introduces a new feature to the codebase and correlates with <MINOR> in SemVer.

• fix patches bugs in the codebase and correlates with <PATCH> in SemVer.

Additional types are allowed and could be used like:

• docs: Documentation only changes.

• style: Changes that do not affect the meaning of the code (white-space, formatting, ...)

• refactor: A code change that neighter fixes a bug nor adds a feature.

• perf: A code that improves performance.

• test: Adding missing tests or correting existing tests.

• build: Changes that affect the build sustem or external dependencies.

• ci: Changes to CI configuration files and scripts.

• chore: Other changes that don't modify src or test files.

• revert: Reverts a previous commit.

BREAKING CHANGES

A commit that has a footer BREAKING CHANGE: or appends a ! after <type>[optional scope] like <type>[optional scope]!:, introduces a breaking change and correlates with <MAJOR> in SemVer.

[Optional Scope]

A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis.

[Optional footer(s)]

One or more footers MAY be provided one blank line after the body.

Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value.

A footer’s token MUST use - in place of whitespace characters.

Ex.:

Reviewed-by: Z
Refs: #123