Conventional Commit Messages

A commit message guideline based on the Conventional Commits Specification.

Commit Message Formats

Standard Commit

<type>(<optional scope>): <description>
_{empty separator line}
<optional body>
_{empty separator line}
<optional footer>

Merge Commit

Merge branch '<branch name>'

^{Follows default git merge message}

Revert Commit

Revert "<reverted commit subject line>"

^{Follows default git revert message}

Initial Commit

init

Types

API relevant changes
- feat commits add or remove a new feature
- fix commits fix a bug
refactor commits rewrite/restructure your code but does not change any API behaviour
- perf commits are special refactor commits that are specific to performance optimisations
model commits commit code related to data model changes
db commits add or update code related to database operations
config commits add or update configuration files (e.g., JSON, YAML, and ENV config files)
style commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
test commits add testing code or correct existing tests
docs commits affect documentation only
build commits affect build components (build tools, CI pipeline, dependencies, project version, etc.)
ops commits affect operational components (infrastructure, deployment, backup, recovery, etc.)
chore commits are miscellaneous commits e.g. modifying .gitignore

Scope (Optional)

The scope provides additional contextual information about the commit, such as a few descriptive words refering to a section of the codebase (e.g., fix(parser):).

It is an optional part of the format
Allowed scopes depends on the specific project
Don't use issue identifiers as scopes

Breaking Changes Indicator (Optional)

Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint

Is an optional part of the format

Description

The description contains a concise description of the change.

It is a mandatory part of the format
Use the imperative, present tense: "change" not "changed" nor "changes"
- Think of This commit will... or This commit should...
Don't capitalize the first letter
No period (.) at the end

Body (Optional)

The body should include the motivation for the change and contrast this with previous behavior.

It is an optional part of the format
Use the imperative, present tense: "change" not "changed" nor "changes"
This is the place to mention issue identifiers and their relations

Footer (Optional)

The footer should contain any information about breaking changes and is also the place to reference issues that this commit refers to.

It is an optional part of the format
Optionally reference an issue by its id.
Breaking changes should start with the word BREAKING CHANGES: followed by space or two newlines. The rest of the commit message is then used for this.

Examples

feat: add email notifications on new direct messages

feat(shopping cart): add the checkout button

feat!: remove ticket list endpoint

refer to JIRA-1337

BREAKING CHANGES: ticket endpoints no longer support list all entities

fix(api): handle empty message in request body

fix(api): fix wrong calculation of request body checksum

fix: add missing parameter to service call

The error occurred because of <reasons>.

perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog

```
build: update dependencies
```
```
build(release): bump version to 1.0.0
```

refactor: implement fibonacci number calculation as recursion

```
style: remove empty line
```

jordan-chisl/conventional-commits-cheatsheet.md