See how a minor change to your commit message style can make a difference.
git commit -m"<type>(<optional scope>): <description>" \ -m"<optional body>" \ -m"<optional footer>"
Note
This cheatsheet is opinionated, however it does not violate the specification of conventional commits
Tip
Take a look at git-conventional-commits a CLI util to ensure these conventions, determine version and generate changelogs.
<type>(<optional scope>): <description> empty line as separator <optional body> empty line as separator <optional footer>
chore: init
Merge branch '<branch name>'
Follows default git merge message
Revert "<reverted commit subject line>"
Follows default git revert message
- Changes relevant to the API or UI:
featCommits that add, adjust or remove a feature to/of/from the API or UIfixCommits that fix an API or UI bug of a precededfeatcommit
refactorCommits that rewrite or restructure code without altering API or UI behaviorperfCommits are special type ofrefactorcommits that specifically improve performance
styleCommits that address code style (e.g., white-space, formatting, missing semi-colons) and do not affect application behaviortestCommits that add missing tests or correct existing onesdocsCommits that exclusively affect documentationbuildCommits that affect build-related components such as build tools, dependencies, project version, ...opsCommits that affect operational aspects like infrastructure (IaC), deployment scripts, CI/CD pipelines, backups, monitoring, or recovery procedures, ...choreCommits that represent tasks like initial commit, modifying.gitignore, ...
The scope provides additional contextual information.
- The scope is an optional part
- Allowed scopes vary and are typically defined by the specific project
- Do not use issue identifiers as scopes
- A commit that introduce breaking changes must be indicated by an
!before the:in the subject line e.g.feat(api)!: remove status endpoint - Breaking changes should be described in the commit footer section, if the commit description isn't sufficiently informative
The description contains a concise description of the change.
- The description is a mandatory part
- Use the imperative, present tense: "change" not "changed" nor "changes"
- Think of
This commit will...orThis commit should...
- Think of
- Do not capitalize the first letter
- Do not end the description with a period (
.) - In case of breaking changes also see breaking changes indicator
The body should include the motivation for the change and contrast this with previous behavior.
- The body is an optional part
- Use the imperative, present tense: "change" not "changed" nor "changes"
The footer should contain issue references and informations about Breaking Changes
- The footer is an optional part, except if the commit introduce breaking changes
- Optionally reference issue identifiers (e.g.,
Closes #123,Fixes JIRA-456) - Breaking Changes must start with the word
BREAKING CHANGE:- For a single line description just add a space after
BREAKING CHANGE: - For a multi line description add two new lines after
BREAKING CHANGE:
- For a single line description just add a space after
- If your next release contains commit with...
- Breaking Changes incremented the major version
- API relevant changes (
featorfix) incremented the minor version
- Else increment the patch version
-
feat: add email notifications on new direct messages -
feat(shopping cart): add the amazing button -
feat!: remove ticket list endpoint refers to JIRA-1337 BREAKING CHANGE: ticket endpoints no longer supports list all entities. -
fix(shopping-cart): prevent order an empty shopping cart -
fix(api): fix wrong calculation of request body checksum -
fix: add missing parameter to service call The error occurred due to <reasons>. -
perf: decrease memory footprint for determine unique 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
Click to expand
- Create a commit-msg hook using git-conventional-commits cli
- create following file in your repository folder
.git/hooks/pre-receive#!/usr/bin/env bash # Pre-receive hook that will block commits with messages that do not follow regex rule commit_msg_type_regex='feat|fix|refactor|style|test|docs|build' commit_msg_scope_regex='.{1,20}' commit_msg_description_regex='.{1,100}' commit_msg_regex="^(${commit_msg_type_regex})(\(${commit_msg_scope_regex}\))?: (${commit_msg_description_regex})\$" merge_msg_regex="^Merge branch '.+'\$" zero_commit="0000000000000000000000000000000000000000" # Do not traverse over commits that are already in the repository excludeExisting="--not --all" error="" while read oldrev newrev refname; do # branch or tag get deleted if [ "$newrev" = "$zero_commit" ]; then continue fi # Check for new branch or tag if [ "$oldrev" = "$zero_commit" ]; then rev_span=`git rev-list $newrev $excludeExisting` else rev_span=`git rev-list $oldrev..$newrev $excludeExisting` fi for commit in $rev_span; do commit_msg_header=$(git show -s --format=%s $commit) if ! [[ "$commit_msg_header" =~ (${commit_msg_regex})|(${merge_msg_regex}) ]]; then echo "$commit" >&2 echo "ERROR: Invalid commit message format" >&2 echo "$commit_msg_header" >&2 error="true" fi done done if [ -n "$error" ]; then exit 1 fi
- ⚠ make
.git/hooks/pre-receiveexecutable (unix:chmod +x '.git/hooks/pre-receive')
MIT License
Copyright (c) [2026] [Bengt brodersen]
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- https://www.conventionalcommits.org/
- https://github.com/angular/angular/blob/master/CONTRIBUTING.md
- http://karma-runner.github.io/1.0/dev/git-commit-msg.html
I changed the Licence from GLPv3 to MIT