{"slug": "conventional-commits-cheatsheet", "title": "Conventional Commits Cheatsheet", "summary": "The article summarizes the Conventional Commits specification, a standardized format for Git commit messages that uses a structured `(): ` format. It defines various commit types like `feat`, `fix`, and `refactor`, explains how to indicate breaking changes with an `!` before the colon, and describes the optional body and footer sections for providing additional context. The cheatsheet also notes that following these conventions can help automate versioning and changelog generation.", "body_md": "# Conventional Commit Messages [![starline](https://starlines.qoo.monster/assets/qoomon/5dfcdf8eec66a051ecd85625518cfd13@gist)](https://github.com/qoomon/starline)\n\nSee how [a minor change](#examples) to your commit message style can make a difference. \n\n
\ngit commit -m\"<type>(<optional scope>): <description>\" \\\n  -m\"<optional body>\" \\\n  -m\"<optional footer>\"\n
\n\n> [!Note] \n> This cheatsheet is opinionated, however it does not violate the specification of [conventional commits](https://www.conventionalcommits.org/)\n\n> [!TIP]\n> Take a look at **[git-conventional-commits](https://github.com/qoomon/git-conventional-commits)** a CLI util to ensure these conventions, determine version and generate changelogs.\n\n## Commit Message Formats\n\n### General Commit\n
\n<type>(<optional scope>): <description>\nempty line as separator\n<optional body>\nempty line as separator\n<optional footer>\n
\n\n### Initial Commit \n```\nchore: init\n```\n\n### Merge Commit\n
\nMerge branch '<branch name>'\n
\nFollows default git merge message\n\n### Revert Commit\n
\nRevert \"<reverted commit subject line>\"\n
\nFollows default git revert message\n\n\n### Types\n- Changes relevant to the API or UI:\n - `feat` Commits that add, adjust or remove a feature to/of/from the API or UI\n - `fix` Commits that fix an API or UI bug of a preceded `feat` commit\n- `refactor` Commits that rewrite or restructure code without altering API or UI behavior\n - `perf` Commits are special type of `refactor` commits that specifically improve performance\n- `style` Commits that address code style (e.g., white-space, formatting, missing semi-colons) and do not affect application behavior\n- `test` Commits that add missing tests or correct existing ones\n- `docs` Commits that exclusively affect documentation\n- `build` Commits that affect build-related components such as build tools, dependencies, project version, ...\n- `ops` Commits that affect operational aspects like infrastructure (IaC), deployment scripts, CI/CD pipelines, backups, monitoring, or recovery procedures, ...\n- `chore` Commits that represent tasks like initial commit, modifying `.gitignore`, ...\n\n### Scopes\nThe `scope` provides additional contextual information.\n* The scope is an **optional** part\n* Allowed scopes vary and are typically defined by the specific project\n* **Do not** use issue identifiers as scopes\n\n### Breaking Changes Indicator\n- A commit that introduce breaking changes **must** be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`\n- Breaking changes **should** be described in the [commit footer section](#footer), if the [commit description](#description) isn't sufficiently informative\n\n### Description\nThe `description` contains a concise description of the change. \n- The description is a **mandatory** part\n- Use the imperative, present tense: \"change\" not \"changed\" nor \"changes\"\n - Think of `This commit will...` or `This commit should...`\n- **Do not** capitalize the first letter\n- **Do not** end the description with a period (`.`)\n- In case of breaking changes also see [breaking changes indicator](#breaking-changes-indicator)\n\n### Body\nThe `body` should include the motivation for the change and contrast this with previous behavior.\n- The body is an **optional** part\n- Use the imperative, present tense: \"change\" not \"changed\" nor \"changes\"\n\n### Footer\nThe `footer` should contain issue references and informations about **Breaking Changes**\n- The footer is an **optional** part, except if the commit introduce breaking changes\n- *Optionally* reference issue identifiers (e.g., `Closes #123`, `Fixes JIRA-456`) \n- **Breaking Changes** **must** start with the word `BREAKING CHANGE:`\n - For a single line description just add a space after `BREAKING CHANGE:`\n - For a multi line description add two new lines after `BREAKING CHANGE:`\n\n### Versioning\n- **If** your next release contains commit with...\n - **Breaking Changes** incremented the **major version**\n - **API relevant changes** (`feat` or `fix`) incremented the **minor version**\n- **Else** increment the **patch version**\n\n\n### Examples\n- ```\n feat: add email notifications on new direct messages\n ```\n- ```\n feat(shopping cart): add the amazing button\n ```\n- ```\n feat!: remove ticket list endpoint\n\n refers to JIRA-1337\n\n BREAKING CHANGE: ticket endpoints no longer supports list all entities.\n ```\n- ```\n fix(shopping-cart): prevent order an empty shopping cart\n ```\n- ```\n fix(api): fix wrong calculation of request body checksum\n ```\n- ```\n fix: add missing parameter to service call\n\n The error occurred due to .\n ```\n- ```\n perf: decrease memory footprint for determine unique visitors by using HyperLogLog\n ```\n- ```\n build: update dependencies\n ```\n- ```\n build(release): bump version to 1.0.0\n ```\n- ```\n refactor: implement fibonacci number calculation as recursion\n ```\n- ```\n style: remove empty line\n ```\n\n---\n \n## Git Hook Scripts to ensure commit message header format\n
\nClick to expand\n \n### commit-msg Hook (local)\n- Create a commit-msg hook using [git-conventional-commits cli](https://github.com/qoomon/git-conventional-commits?tab=readme-ov-file#automatically-validate-commit-message-convention-before-commit)\n\n### pre-receive Hook (server side)\n- create following file in your repository folder `.git/hooks/pre-receive`\n ```shell\n #!/usr/bin/env bash\n\n # Pre-receive hook that will block commits with messages that do not follow regex rule\n\n commit_msg_type_regex='feat|fix|refactor|style|test|docs|build'\n commit_msg_scope_regex='.{1,20}'\n commit_msg_description_regex='.{1,100}'\n commit_msg_regex=\"^(${commit_msg_type_regex})(\\(${commit_msg_scope_regex}\\))?: (${commit_msg_description_regex})\\$\"\n merge_msg_regex=\"^Merge branch '.+'\\$\"\n\n zero_commit=\"0000000000000000000000000000000000000000\"\n\n # Do not traverse over commits that are already in the repository\n excludeExisting=\"--not --all\"\n\n error=\"\"\n while read oldrev newrev refname; do\n # branch or tag get deleted\n if [ \"$newrev\" = \"$zero_commit\" ]; then\n continue\n fi\n\n # Check for new branch or tag\n if [ \"$oldrev\" = \"$zero_commit\" ]; then\n rev_span=`git rev-list $newrev $excludeExisting`\n else\n rev_span=`git rev-list $oldrev..$newrev $excludeExisting`\n fi\n\n for commit in $rev_span; do\n commit_msg_header=$(git show -s --format=%s $commit)\n if ! [[ \"$commit_msg_header\" =~ (${commit_msg_regex})|(${merge_msg_regex}) ]]; then\n echo \"$commit\" >&2\n echo \"ERROR: Invalid commit message format\" >&2\n echo \"$commit_msg_header\" >&2\n error=\"true\"\n fi\n done\n done\n\n if [ -n \"$error\" ]; then\n exit 1\n fi\n ```\n* ⚠ make `.git/hooks/pre-receive` executable (unix: `chmod +x '.git/hooks/pre-receive'`)\n\n
\n\n-----\n## References\n- https://www.conventionalcommits.org/\n- https://github.com/angular/angular/blob/master/CONTRIBUTING.md\n- http://karma-runner.github.io/1.0/dev/git-commit-msg.html\n
\n\n- https://github.com/github/platform-samples/tree/master/pre-receive-hooks \n- https://github.community/t5/GitHub-Enterprise-Best-Practices/Using-pre-receive-hooks-in-GitHub-Enterprise/ba-p/13863\n\n", "url": "https://wpnews.pro/news/conventional-commits-cheatsheet", "canonical_source": "https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13", "published_at": "2018-12-18 11:33:08+00:00", "updated_at": "2026-05-22 22:05:57.986574+00:00", "lang": "en", "topics": ["developer-tools", "open-source"], "entities": ["Conventional Commits", "git-conventional-commits"], "alternates": {"html": "https://wpnews.pro/news/conventional-commits-cheatsheet", "markdown": "https://wpnews.pro/news/conventional-commits-cheatsheet.md", "text": "https://wpnews.pro/news/conventional-commits-cheatsheet.txt", "jsonld": "https://wpnews.pro/news/conventional-commits-cheatsheet.jsonld"}}