Instantly share code, notes, and snippets. Star 5,000+ ( 5,000+ ) You must be signed in to star a gist Fork 664 ( 664 ) You must be signed in to fork a gist Embed Select an option Embed Embed this gist in your website. Share Copy sharable link for this gist. Clone via HTTPS Clone using the web URL. No results found Learn more about clone URLs Clone this repository at &lt;script src=&quot;https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13.js&quot;&gt;&lt;/script&gt; Embed Embed this gist in your website. Share Copy sharable link for this gist. Clone via HTTPS Clone using the web URL. No results found Save qoomon/5dfcdf8eec66a051ecd85625518cfd13 to your computer and use it in GitHub Desktop. Embed Embed this gist in your website. Share Copy sharable link for this gist. Clone via HTTPS Clone using the web URL. No results found See how a minor change to your commit message style can make a difference. This cheatsheet is opinionated, however it does not violate the specification of conventional commits Take a look at git-conventional-commits a CLI util to ensure these conventions, determine version and generate changelogs. Commit Message Formats Follows default git merge message Follows default git revert message Changes relevant to the API or UI: feat Commits that add, adjust or remove a feature to/of/from the API or UI fix Commits that fix an API or UI bug of a preceded feat commit feat Commits that add, adjust or remove a feature to/of/from the API or UI fix Commits that fix an API or UI bug of a preceded feat commit refactor Commits that rewrite or restructure code without altering API or UI behavior perf Commits are special type of refactor commits that specifically improve performance perf Commits are special type of refactor commits that specifically improve performance style Commits that address code style (e.g., white-space, formatting, missing semi-colons) and do not affect application behavior test Commits that add missing tests or correct existing ones docs Commits that exclusively affect documentation build Commits that affect build-related components such as build tools, dependencies, project version, ... ops Commits that affect operational aspects like infrastructure (IaC), deployment scripts, CI/CD pipelines, backups, monitoring, or recovery procedures, ... chore Commits 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 Breaking Changes Indicator 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... or This commit should... Think of This commit will... or This commit should... 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 BREAKING CHANGE: For a multi line description add two new lines after BREAKING CHANGE: If your next release contains commit with... Breaking Changes incremented the major version API relevant changes ( feat or fix ) incremented the minor version Breaking Changes incremented the major version API relevant changes ( feat or fix ) 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 Git Hook Scripts to ensure commit message header format commit-msg Hook (local) Create a commit-msg hook using git-conventional-commits cli pre-receive Hook (server side) 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-receive executable (unix: chmod +x '.git/hooks/pre-receive' ) 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 https://github.com/github/platform-samples/tree/master/pre-receive-hooks https://github.community/t5/GitHub-Enterprise-Best-Practices/Using-pre-receive-hooks-in-GitHub-Enterprise/ba-p/13863 RobSmyth commented Dec 3, 2025 Hi @JohnnyWalkerDigital , behavior(execute): disable logs with ... -- --help I see what you mean, you're changing how the system operates, hence "behaviour". However I wonder if it would fit in chore? Do you think this change needs to be user documentation, release notes, or bump the version? I wonder if your using Semmantic Versioning as that would impact process here. dexoryn commented Dec 4, 2025 Thanks, when the project structure completely changed and the version completely upgraded, what prefix we can use? raed-bash commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . what if we fix typing errors? what should we put before a commit message? JohnnyWalkerDigital commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . When to use each prefix Did you fix a bug? Yes : It's fix: No : Did you change functionality or affect UI? Yes : It's feat: No : Did you add or change tests? Yes : It's test: No : Did you change code style or formatting (doesn't affect code behaviour)? Yes : It's style: No : Did you make changes to documentation? Yes : It's docs: No : Did you change how the project is built (eg. packages, dependencies, dockerfile, etc)? Yes : It's build: No : Did you change something related to devops (eg. operational, deployment/CI/linting pipelines)? Yes : It's ops: No : Did you complete a maintenance task or other non-code task for the project (eg. modifying .gitignore or making initial commit)? Yes : It's chore: No : Did you rewrite or restructure code specifically for performance? Yes : It's perf: No : It's refactor: Also Mermaid Gist . ttytm commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @JohnnyWalkerDigital Attempt at a flow chart: Did you fix a bug? No: Did you change functionality or affect UI?

Yes: It's feat: No: Did you add or change tests? Yes: It's test: No: Did you change code style or formatting? Yes: It's style: No: Did you make changes to documentation? Yes: It's docs: No: Did you change things related to build or deploy operations? Yes: It's build: No: Did you change something related to devops, infrastructure or backups? No: Did you complete a maintenance task or other non-code task for the project (eg. modifying .gitignore or making initial commit)? Yes: It's chore: No: Did you rewrite or restructure code specifically for performance? Yes: It's perf: No: It's refactor: I think using a flowchart makes the solution more complicated. AFAIK GitHub renders mermaid diagrams, so it should become visible here: Since every decision is a simple yes/no that ends in exactly one category, a decision table (or ordered checklist) is likely a better fit. Checklist attempt based on the order of the original answer If it fixes a bug → fix Else if it changes functionality or UI → feat Else if it adds or changes tests → test Else if it changes code style or formatting → style Else if it changes documentation → docs Else if it affects build or deploy → build Else if it affects devops, infrastructure, or backups → ops Else if it’s a maintenance or non-code task → chore Else if it improves performance → perf Else → refactor Table attempt based on the order of the original answer Table attempt with structural improvement While the order in your answer is already a strong foundation. I think the priority order can be improved. Attempt below trying to match the current conventional Commit semantics: Overall the intent here is minimizing mental load, improve long-term consistency, use chore as true fallback to preventing it's lazy overuse. AchiraNadeeshan commented Dec 6, 2025 correct typo "I case" to "In case" in commit message description rules. JohnnyWalkerDigital commented Dec 9, 2025 Personally I find ops: to be unnecessarily detailed with little benefit over using build: . I also think perf: is unnecessary... the description of a refactor: can indicate performance improvements. qoomon commented Dec 15, 2025 @AchiraNadeeshan thanks, I fixed it qoomon commented Dec 15, 2025 I also think perf: is unnecessary... the description of a refactor: can indicate performance improvements. You don't have to use perf: , however it can be handy for generating changelogs automatically because in general refactoring: commits (especially those that only improves code readability) are not worth mentioning in a change log for users except performance improvements JohnnyWalkerDigital commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @qoomon Yep, I get that logic. Makes sense 👍 I still don't understand the inclusion of ops: . It's not part of the official specification , and if I'm having to stop and think about which prefix to use, then something has gone wrong. qoomon commented Dec 15, 2025 @JohnnyWalkerDigital what would you label a commit that changes backup mechanism e.g. the schedule JohnnyWalkerDigital commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @JohnnyWalkerDigital what would you label a commit that changes backup mechanism e.g. the schedule DevOps are always handled at a platform-level on projects I work on, not a code level. But if they were code-level then I'd just consider it another feature of the code (so feat: , refactor: or fix: depending on what I was doing). If I was altering something on the platform-level via files in the repo (eg. altering the backup schedule somehow) I guess I'd choose chore: . qoomon commented Dec 16, 2025 IMHO ops: would be a better fit. It can not be feat or fix because no api change for the clients and refactoring is also not reflecting the change. and chore seems also not the right choice JohnnyWalkerDigital commented Dec 16, 2025 Sorry, maybe I wasn't clear. I said, if a backup occurred at code-level, then it would be feat: , refactor: or fix: because it would be a feature for the software. This is standard for all features of the software. If it was altering something at the platform level, then it fits with the description of chore: IMO. These descriptions, and the related diagram, is quite helpful I think. conventional-commits/conventionalcommits.org#634 (comment) qoomon commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @JohnnyWalkerDigital It depends if your referring to an OSS project I would agree then it's a feat: or fix: commit. However if it's an closed source company project then it would be ops: because this change does not change any behaviour a client is able to recognise JohnnyWalkerDigital commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @qoomon I think it's irrelevant if it's OSS or not. "Backup" is vaguely defined. It might be an important feature of the software itself, or it might be something at a platform level, as I said. That is the only difference. qoomon commented Dec 22, 2025 By OSS I mean if the change affects the clients/users RedCMD commented Jan 9, 2026 what about improving the performance of a test? still just test: or change to perf: JohnnyWalkerDigital commented Jan 9, 2026 what about improving the performance of a test? still just test: or change to perf: If you follow the flow I made , it answers this for you. (It's also why I didn't do what ttytm did in their version.) qoomon commented Jan 11, 2026 @RedCMD it's test: . perf: is an special refactor: commit. And refactor should only be used for feature related refactoring. JohnnyWalkerDigital commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . While the order in your answer is already a strong foundation. I think the priority order can be improved. Attempt below trying to match the current conventional Commit semantics: The problem with this priority order (and the reason I didn't do it) is because it means if you refactor a test then you're told to label your commit refactor: when it should be labelled test: . mts2410 commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . I would like to challenge the restrictiveness of the rule stating that the issue identifier should not appear in the scope . Including the issue identifier in the scope -or at least somewhere in the first line of the commit message-provides significant practical value. Many Git providers and tools display only the first line of a commit message in history views by default, making it much easier to quickly scan commits and associate them with their corresponding issues without needing to open each commit individually. Another example is a command such as git log --left-right --oneline A...B which is a standard way of comparing commits between branches, and having issue identifiers in the first line of commits provides clear practical value. I believe this rule is a bit too restrictive and overlooks a practical usability advantage. It may be worth reconsidering or allowing flexibility in this case. qoomon commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @mts2410 just my humble thoughts regarding issue IDs the scope is meant to be a logical section of you project not a link to an issue i would rather search or filter commits if i need to know which commit belongs to which issue. In general the issue link should just why the change was made not what. The what should be described as part of the commit message (if possible i the first line) If you still want to add a issue tracker reference in the first line of the commit message you should add it in front or at the end of the description dengqiaoyu commented Jun 17, 2026 @qoomon Hi, thanks for this comprehensive cheatsheet! Could you clarify the license for conventional-commits-cheatsheet.md (e.g., MIT, BSD, or GPL)? Would it be okay to use it in our project as an agent prompt, with attribution via the link above? gabrielsclimaco commented Jun 30, 2026 I feel like there's should be a different set of scope for infrastructure as a code. Tasks of completely different scopes end up always falling into chore or refactor, kind of loses the point to me... qoomon commented Jul 1, 2026 @gabrielsclimaco I think of infrastructure as art of the project source. That means if you have change on you infrastructure that does not affect the APIs or UIs then it should be a simple refactor commit or a perf refactor commit in some cases. If you need to change or adjust the infrastructure as part of a new feature then it's a feat commit. In my opinion its never chore qoomon commented Jul 1, 2026 @dengqiaoyu yes you can use it as long as you mention it. I also added a License Bade to the Gist qoomon commented Aug 29, 2026 I changed the Licence from GLPv3 to MIT OmegaRelay commented Sep 8, 2026 Hi @qoomon thanks for creating this helpful overview I had noticed this: API relevant changes (feat or fix) incremented the minor version Although this doesn't technically violate the specification; the spec does suggest that fix should increment the patch version, not the minor: https://www.conventionalcommits.org/en/v1.0.0/#how-does-this-relate-to-semver qoomon commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . @OmegaRelay Oh you are completely right. I'll fix it. Thanks for mentioning