DaveLak · July 18, 2025 04:27 · Jul 8, 2025 · Jul 8, 2025 · Jun 25, 2025 · Jun 25, 2025
diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -1,14 +1,16 @@
 # Conventional Commit Messages [![starline](https://starlines.qoo.monster/assets/qoomon/5dfcdf8eec66a051ecd85625518cfd13@gist)](https://github.com/qoomon/starline)
 
 See how [a minor change](#examples) to your commit message style can make a difference. 
-This cheatsheet is opinionated but does not violate the specification of [conventional commits](https://www.conventionalcommits.org/)
 
 <pre>
 git commit -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>" \
   -m"<b><a href="#body">&lt;optional body&gt;</a></b>" \
   -m"<b><a href="#footer">&lt;optional footer&gt;</a></b>"
 </pre>
 
+> [!Note] 
+> This cheatsheet is opinionated, however it does not violate the specification of [conventional commits](https://www.conventionalcommits.org/)
+
 > [!TIP]
 > 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.
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -1,6 +1,7 @@
 # Conventional Commit Messages [![starline](https://starlines.qoo.monster/assets/qoomon/5dfcdf8eec66a051ecd85625518cfd13@gist)](https://github.com/qoomon/starline)
 
 See how [a minor change](#examples) to your commit message style can make a difference. 
+This cheatsheet is opinionated but does not violate the specification of [conventional commits](https://www.conventionalcommits.org/)
 
 <pre>
 git commit -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>" \

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -81,7 +81,9 @@ The `body` should include the motivation for the change and contrast this with p
 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** should start with the word `BREAKING CHANGE:` followed by space or two newlines. The rest of the commit message is then used for this.
+- **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:`
 
 ### Versioning
 - **If** your next release contains commit with...

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -64,12 +64,13 @@ The `scope` provides additional contextual information.
 - Breaking changes **should** be described in the [commit footer section](#footer), if the [commit description](#description) isn't sufficiently informative
 
 ### Description
-The `description` contains a concise description of the change.
+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...`
 - **Do not** capitalize the first letter
 - **Do not** end the description with a period (`.`)
+- I case of breaking changes also see [breaking changes indicator](#breaking-changes-indicator)
 
 ### Body
 The `body` should include the motivation for the change and contrast this with previous behavior.

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -16,9 +16,9 @@ git commit -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scope
 ### General Commit
 <pre>
 <b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>
-<sub>empty separator line</sub>
+<sub>empty line as separator</sub>
 <b><a href="#body">&lt;optional body&gt;</a></b>
-<sub>empty separator line</sub>
+<sub>empty line as separator</sub>
 <b><a href="#footer">&lt;optional footer&gt;</a></b>
 </pre>
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -60,7 +60,7 @@ The `scope` provides additional contextual information.
 * **Do not** use issue identifiers as scopes
 
 ### Breaking Changes Indicator
-- Breaking changes **must** be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`
+- 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](#footer), if the [commit description](#description) isn't sufficiently informative
 
 ### Description

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -60,7 +60,7 @@ The `scope` provides additional contextual information.
 * **Do not** use issue identifiers as scopes
 
 ### Breaking Changes Indicator
-- Breaking changes *must* be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`
+- 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](#footer), if the [commit description](#description) isn't sufficiently informative
 
 ### Description

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -60,8 +60,8 @@ The `scope` provides additional contextual information.
 * **Do not** use issue identifiers as scopes
 
 ### Breaking Changes Indicator
-- Breaking changes *should* be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`
-- Breaking changes **must** be described in the [commit footer section](#footer)    
+- 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](#footer), if the [commit description](#description) isn't sufficiently informative
 
 ### Description
 The `description` contains a concise description of the change.

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -22,6 +22,11 @@ git commit -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scope
 <b><a href="#footer">&lt;optional footer&gt;</a></b>
 </pre>
 
+### Initial Commit 
+```
+chore: init
+```
+
 ### Merge Commit
 <pre>
 Merge branch '<b>&lt;branch name&gt;</b>'
@@ -34,10 +39,6 @@ Revert "<b>&lt;reverted commit subject line&gt;</b>"
 </pre>
 <sup>Follows default git revert message</sup>
 
-### Initial Commit 
-```
-chore: init
-```
 
 ### Types
 - Changes relevant to the API or UI:

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -9,7 +9,7 @@ git commit -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scope
 </pre>
 
 > [!TIP]
-> 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
+> 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.
 
 ## Commit Message Formats
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -3,8 +3,7 @@
 See how [a minor change](#examples) to your commit message style can make a difference. 
 
 <pre>
-git commit \
-  -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>" \
+git commit -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>" \
   -m"<b><a href="#body">&lt;optional body&gt;</a></b>" \
   -m"<b><a href="#footer">&lt;optional footer&gt;</a></b>"
 </pre>

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -50,7 +50,6 @@ chore: init
 - `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, CI/CD pipelines, ...
-- `ops` Commits affecting operational aspects like infrastructure, deployment processes, backup, or recovery procedures.
 - `ops` Commits that affect operational components like infrastructure, deployment, backup, recovery procedures, ...
 - `chore` Miscellaneous commits e.g. modifying `.gitignore`, ...
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -2,12 +2,19 @@
 
 See how [a minor change](#examples) to your commit message style can make a difference. 
 
+<pre>
+git commit \
+  -m"<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>" \
+  -m"<b><a href="#body">&lt;optional body&gt;</a></b>" \
+  -m"<b><a href="#footer">&lt;optional footer&gt;</a></b>"
+</pre>
+
 > [!TIP]
 > 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
 
 ## Commit Message Formats
 
-### Default
+### General Commit
 <pre>
 <b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>
 <sub>empty separator line</sub>

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -34,52 +34,51 @@ chore: init
 ```
 
 ### Types
-- API or UI relevant changes
-    - `feat` Commits, that add or remove a new feature to the API or UI
-    - `fix` Commits, that fix an API or UI bug of a preceded `feat` commit
-- `refactor` Commits, that rewrite/restructure your code, however do not change any API or UI behaviour
-    - `perf` Commits are special `refactor` commits, that improve performance
-- `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
-- `test` Commits, that add missing tests or correcting existing tests
-- `docs` Commits, that affect documentation only
-- `build` Commits, that affect build components like build tools, dependencies, project version, ci pipelines, ...
-- `ops` Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
-- `chore` Miscellaneous commits e.g. modifying `.gitignore`
+- Changes relevant to the API or UI:
+    - `feat` Commits that add, adjust or remove a new feature to 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
+- `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, CI/CD pipelines, ...
+- `ops` Commits affecting operational aspects like infrastructure, deployment processes, backup, or recovery procedures.
+- `ops` Commits that affect operational components like infrastructure, deployment, backup, recovery procedures, ...
+- `chore` Miscellaneous commits e.g. modifying `.gitignore`, ...
 
 ### Scopes
 The `scope` provides additional contextual information.
-* Is an **optional** part of the format
-* Allowed Scopes depend on the specific project
-* Don't use issue identifiers as scopes
+* 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
-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
-- Breaking changes **must** be described in the [commit footer section](#footer)
+- Breaking changes *should* be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`
+- Breaking changes **must** be described in the [commit footer section](#footer)    
 
 ### Description
 The `description` contains a concise description of the change.
-- It is a **mandatory** part of the format
+- 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...`
-- Don't capitalize the first letter
-- No dot (`.`) at the end
+- **Do not** capitalize the first letter
+- **Do not** end the description with a period (`.`)
 
 ### Body
 The `body` should include the motivation for the change and contrast this with previous behavior.
-- Is an **optional** part of the format
+- The body is an **optional** part
 - Use the imperative, present tense: "change" not "changed" nor "changes"
-- This is the place to mention issue identifiers and their relations
 
 ### Footer
-The `footer` should contain any information about **Breaking Changes** and is also the place to **reference Issues** that this commit refers to.
-- Is an **optional** part of the format
-- **optionally** reference an issue by its id.
+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** should start with the word `BREAKING CHANGE:` followed by space or two newlines. The rest of the commit message is then used for this.
 
 ### Versioning
 - **If** your next release contains commit with...
-   - **breaking changes** incremented the **major version**
+   - **Breaking Changes** incremented the **major version**
    - **API relevant changes** (`feat` or `fix`) incremented the **minor version**
 - **Else** increment the **patch version**
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -110,7 +110,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
   The error occurred due to <reasons>.
   ```
 - ```
-  perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog
+  perf: decrease memory footprint for determine unique visitors by using HyperLogLog
   ```
 - ```
   build: update dependencies

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -28,7 +28,7 @@ Revert "<b>&lt;reverted commit subject line&gt;</b>"
 </pre>
 <sup>Follows default git revert message</sup>
 
-### Inital Commit 
+### Initial Commit 
 ```
 chore: init
 ```

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -42,7 +42,7 @@ chore: init
 - `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
 - `test` Commits, that add missing tests or correcting existing tests
 - `docs` Commits, that affect documentation only
-- `build` Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
+- `build` Commits, that affect build components like build tools, dependencies, project version, ci pipelines, ...
 - `ops` Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
 - `chore` Miscellaneous commits e.g. modifying `.gitignore`
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -36,7 +36,7 @@ chore: init
 ### Types
 - API or UI relevant changes
     - `feat` Commits, that add or remove a new feature to the API or UI
-    - `fix` Commits, that fix a API or UI bug of a preceded `feat` commit
+    - `fix` Commits, that fix an API or UI bug of a preceded `feat` commit
 - `refactor` Commits, that rewrite/restructure your code, however do not change any API or UI behaviour
     - `perf` Commits are special `refactor` commits, that improve performance
 - `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -3,7 +3,7 @@
 See how [a minor change](#examples) to your commit message style can make a difference. 
 
 > [!TIP]
-> Have 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
+> 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
 
 ## Commit Message Formats
 
@@ -49,7 +49,7 @@ chore: init
 ### Scopes
 The `scope` provides additional contextual information.
 * Is an **optional** part of the format
-* Allowed Scopes depends on the specific project
+* Allowed Scopes depend on the specific project
 * Don't use issue identifiers as scopes
 
 ### Breaking Changes Indicator
@@ -59,7 +59,7 @@ Breaking changes should be indicated by an `!` before the `:` in the subject lin
 
 ### Description
 The `description` contains a concise description of the change.
-- Is a **mandatory** part of the format
+- 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
@@ -96,7 +96,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
 
   refers to JIRA-1337
 
-  BREAKING CHANGE: ticket enpoints no longer supports list all entites.
+  BREAKING CHANGE: ticket endpoints no longer supports list all entities.
   ```
 - ```
   fix(shopping-cart): prevent order an empty shopping cart
@@ -107,7 +107,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
 - ```
   fix: add missing parameter to service call
 
-  The error occurred because of <reasons>.
+  The error occurred due to <reasons>.
   ```
 - ```
   perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog
@@ -139,7 +139,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
   ```shell
   #!/usr/bin/env bash
 
-  # Pre-receive hook that will block commits with messges that do not follow regex rule
+  # 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}'

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -1,4 +1,4 @@
-# Conventional Commit Messages [![starline](https://starlines.qoo.monster/assets/gists/5dfcdf8eec66a051ecd85625518cfd13)](https://github.com/qoomon/starline)
+# Conventional Commit Messages [![starline](https://starlines.qoo.monster/assets/qoomon/5dfcdf8eec66a051ecd85625518cfd13@gist)](https://github.com/qoomon/starline)
 
 See how [a minor change](#examples) to your commit message style can make a difference. 
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -96,7 +96,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
 
   refers to JIRA-1337
 
-  BREAKING CHANGES: ticket enpoints no longer supports list all entites.
+  BREAKING CHANGE: ticket enpoints no longer supports list all entites.
   ```
 - ```
   fix(shopping-cart): prevent order an empty shopping cart

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -55,7 +55,7 @@ The `scope` provides additional contextual information.
 ### Breaking Changes Indicator
 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
-- Breaking changes must be described in the [commit footer section](#footer)
+- Breaking changes **must** be described in the [commit footer section](#footer)
 
 ### Description
 The `description` contains a concise description of the change.

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -55,7 +55,7 @@ The `scope` provides additional contextual information.
 ### Breaking Changes Indicator
 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
-- Should be use in combination with [`BREAKING CHANGE:` in the commit footer section](#footer)
+- Breaking changes must be described in the [commit footer section](#footer)
 
 ### Description
 The `description` contains a concise description of the change.

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -55,6 +55,7 @@ The `scope` provides additional contextual information.
 ### Breaking Changes Indicator
 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
+- Should be use in combination with [`BREAKING CHANGE:` in the commit footer section](#footer)
 
 ### Description
 The `description` contains a concise description of the change.
@@ -74,7 +75,7 @@ The `body` should include the motivation for the change and contrast this with p
 The `footer` should contain any information about **Breaking Changes** and is also the place to **reference Issues** that this commit refers to.
 - 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.
+- **Breaking Changes** should start with the word `BREAKING CHANGE:` followed by space or two newlines. The rest of the commit message is then used for this.
 
 ### Versioning
 - **If** your next release contains commit with...

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -35,9 +35,9 @@ chore: init
 
 ### Types
 - API or UI relevant changes
-    - `feat` Commits, that adds or remove a new feature to the API or UI
-    - `fix` Commits, that fixes a API or UI bug of a preceded `feat` commit
-- `refactor` Commits, that rewrite/restructure your code, however does not change any API behaviour
+    - `feat` Commits, that add or remove a new feature to the API or UI
+    - `fix` Commits, that fix a API or UI bug of a preceded `feat` commit
+- `refactor` Commits, that rewrite/restructure your code, however do not change any API or UI behaviour
     - `perf` Commits are special `refactor` commits, that improve performance
 - `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
 - `test` Commits, that add missing tests or correcting existing tests

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -34,9 +34,9 @@ chore: init
 ```
 
 ### Types
-- API relevant changes
-    - `feat` Commits, that adds or remove a new feature
-    - `fix` Commits, that fixes a bug of a preceded `feat` commit
+- API or UI relevant changes
+    - `feat` Commits, that adds or remove a new feature to the API or UI
+    - `fix` Commits, that fixes a API or UI bug of a preceded `feat` commit
 - `refactor` Commits, that rewrite/restructure your code, however does not change any API behaviour
     - `perf` Commits are special `refactor` commits, that improve performance
 - `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -34,17 +34,17 @@ chore: init
 ```
 
 ### Types
-* API relevant changes
-    * `feat` Commits, that adds or remove a new feature
-    * `fix` Commits, that fixes a bug of a preceded `feat` commit
-* `refactor` Commits, that rewrite/restructure your code, however does not change any API behaviour
-    * `perf` Commits are special `refactor` commits, that improve performance
-* `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
-* `test` Commits, that add missing tests or correcting existing tests
-* `docs` Commits, that affect documentation only
-* `build` Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
-* `ops` Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
-* `chore` Miscellaneous commits e.g. modifying `.gitignore`
+- API relevant changes
+    - `feat` Commits, that adds or remove a new feature
+    - `fix` Commits, that fixes a bug of a preceded `feat` commit
+- `refactor` Commits, that rewrite/restructure your code, however does not change any API behaviour
+    - `perf` Commits are special `refactor` commits, that improve performance
+- `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
+- `test` Commits, that add missing tests or correcting existing tests
+- `docs` Commits, that affect documentation only
+- `build` Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
+- `ops` Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
+- `chore` Miscellaneous commits e.g. modifying `.gitignore`
 
 ### Scopes
 The `scope` provides additional contextual information.
@@ -54,73 +54,73 @@ The `scope` provides additional contextual information.
 
 ### Breaking Changes Indicator
 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
+- Is an **optional** part of the format
 
 ### Description
 The `description` contains a concise description of the change.
-* 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 dot (`.`) at the end
+- 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 dot (`.`) at the end
 
 ### Body
 The `body` should include the motivation for the change and contrast this with previous behavior.
-* 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
+- 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
 The `footer` should contain any information about **Breaking Changes** and is also the place to **reference Issues** that this commit refers to.
-* 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.
+- 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.
 
 ### Versioning
-* If your next release contains commit with...
-   * **breaking changes** the **major version** should be incremented
-   * API relevant changes (`feat`, `fix`) the **minor version** should be incremented
-* Increment the patch version otherwise.
+- **If** your next release contains commit with...
+   - **breaking changes** incremented the **major version**
+   - **API relevant changes** (`feat` or `fix`) incremented the **minor version**
+- **Else** increment the **patch version**
 
 
 ### Examples
-* ```
+- ```
   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 CHANGES: ticket enpoints no longer supports list all entites.
   ```
-* ```
+- ```
   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 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
   ```
 
@@ -131,10 +131,10 @@ The `footer` should contain any information about **Breaking Changes** and is al
 <summary>Click to expand</summary>
 
 ### commit-msg Hook (local)
-* 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)
+- 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)
 
 ### pre-receive Hook (server side)
-* create following file in your repository folder `.git/hooks/pre-receive`
+- create following file in your repository folder `.git/hooks/pre-receive`
   ```shell
   #!/usr/bin/env bash
 
@@ -186,11 +186,11 @@ The `footer` should contain any information about **Breaking Changes** and is al
 
 -----
 ## References
-* 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://www.conventionalcommits.org/
+- https://github.com/angular/angular/blob/master/CONTRIBUTING.md
+- http://karma-runner.github.io/1.0/dev/git-commit-msg.html
 <br>
 
-* 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
+- 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
 
diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -36,7 +36,7 @@ chore: init
 ### Types
 * API relevant changes
     * `feat` Commits, that adds or remove a new feature
-    * `fix` Commits, that fixes a bug
+    * `fix` Commits, that fixes a bug of a preceded `feat` commit
 * `refactor` Commits, that rewrite/restructure your code, however does not change any API behaviour
     * `perf` Commits are special `refactor` commits, that improve performance
 * `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
@@ -76,6 +76,12 @@ The `footer` should contain any information about **Breaking Changes** and is al
 * **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.
 
+### Versioning
+* If your next release contains commit with...
+   * **breaking changes** the **major version** should be incremented
+   * API relevant changes (`feat`, `fix`) the **minor version** should be incremented
+* Increment the patch version otherwise.
+
 
 ### Examples
 * ```

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -1,4 +1,4 @@
-# Conventional Commit Messages [![starline](https://github-starline.vercel.app/gists/5dfcdf8eec66a051ecd85625518cfd13)](https://github.com/qoomon/starline)
+# Conventional Commit Messages [![starline](https://starlines.qoo.monster/assets/gists/5dfcdf8eec66a051ecd85625518cfd13)](https://github.com/qoomon/starline)
 
 See how [a minor change](#examples) to your commit message style can make a difference.