panevka · April 3, 2025 18:21 · Mar 16, 2025 · Mar 9, 2025 · Mar 9, 2025 · Mar 9, 2025
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. 
 

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/gist/5dfcdf8eec66a051ecd85625518cfd13)](https://github.com/qoomon/starline)
+# Conventional Commit Messages [![starline](https://github-starline.vercel.app/gists/5dfcdf8eec66a051ecd85625518cfd13)](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
@@ -1,4 +1,4 @@
-# Conventional Commit Messages ![Starline](https://github-starline.vercel.app/qoomon/5dfcdf8eec66a051ecd85625518cfd13@gist)
+# Conventional Commit Messages [![starline](https://github-starline.vercel.app/gist/5dfcdf8eec66a051ecd85625518cfd13)](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
@@ -1,4 +1,4 @@
-# Conventional Commit Messages <sub><img src="https://img.icons8.com/dusk/1600/commit-git.png" height="64" /></sub>
+# Conventional Commit Messages ![Starline](https://github-starline.vercel.app/qoomon/5dfcdf8eec66a051ecd85625518cfd13@gist)
 
 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
@@ -92,7 +92,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
   BREAKING CHANGES: ticket enpoints no longer supports list all entites.
   ```
 * ```
-  fix(api): handle empty message in request body
+  fix(shopping-cart): prevent order an empty shopping cart
   ```
 * ```
   fix(api): fix wrong calculation of request body checksum

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 and generate verion and changelogs
+> 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
 
 ## Commit Message Formats
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -30,7 +30,7 @@ Revert "<b>&lt;reverted commit subject line&gt;</b>"
 
 ### Inital Commit 
 ```
-init
+chore: init
 ```
 
 ### Types

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -125,24 +125,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
 <summary>Click to expand</summary>
 
 ### commit-msg Hook (local)
-* ensure `node` and `npx` command is installed on your local machine
-* create following file in your local repository folder`.git-hooks/commit-msg`
-  ```shell
-  #!/usr/bin/env sh
-
-  commit_message="$1"
-  # exit with a non zero exit code incase of an invalid commit message
-
-  # use git-conventional-commits, see https://github.com/qoomon/git-conventional-commits
-  npx git-conventional-commits commit-msg-hook "$commit_message"
-
-  # or verify $commit_message with your own tooling
-  # ...
-
-  ```
-* ⚠ make `.git-hooks/commit-msg` executable (unix: `chmod +x '.git-hooks/commit-msg'`)
-* set git hook directory to `.githooks`  `git config core.hooksPath '.git-hooks'`
-* commit `.git-hooks` directory if you want to share them with your team, they only need to call the git config command once after cloning the repository
+* 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`

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -121,7 +121,9 @@ The `footer` should contain any information about **Breaking Changes** and is al
 ---
 
 ## Git Hook Scripts to ensure commit message header format
-
+<details>
+<summary>Click to expand</summary>
+
 ### commit-msg Hook (local)
 * ensure `node` and `npx` command is installed on your local machine
 * create following file in your local repository folder`.git-hooks/commit-msg`
@@ -191,6 +193,8 @@ The `footer` should contain any information about **Breaking Changes** and is al
   ```
 * ⚠ make `.git/hooks/pre-receive` executable (unix: `chmod +x '.git/hooks/pre-receive'`)
 
+</details>
+
 -----
 ## References
 * https://www.conventionalcommits.org/

diff --git a/conventional_commit_messages_cheatsheet.md → conventional-commits-cheatsheet.md b/conventional_commit_messages_cheatsheet.md → conventional-commits-cheatsheet.md
diff --git a/conventional_commit_messages.md → conventional_commit_messages_cheatsheet.md b/conventional_commit_messages.md → conventional_commit_messages_cheatsheet.md
diff --git a/conventional_commit_messages.md b/conventional_commit_messages.md
@@ -109,7 +109,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
   build: update dependencies
   ```
 * ```
-  build(release): `bump version to 1.0.0
+  build(release): bump version to 1.0.0
   ```
 * ```
   refactor: implement fibonacci number calculation as recursion

diff --git a/conventional_commit_messages.md b/conventional_commit_messages.md
@@ -1,6 +1,6 @@
 # Conventional Commit Messages <sub><img src="https://img.icons8.com/dusk/1600/commit-git.png" height="64" /></sub>
 
-See how a [minor change](#examples) to your commit message style can make a difference. 
+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 and generate verion and changelogs

diff --git a/conventional_commit_messages.md b/conventional_commit_messages.md
@@ -118,6 +118,7 @@ The `footer` should contain any information about **Breaking Changes** and is al
   style: remove empty line
   ```
 
+---
 
 ## Git Hook Scripts to ensure commit message header format
 

diff --git a/conventional_commit_messages.md b/conventional_commit_messages.md
@@ -1,4 +1,4 @@
-# Conventional Commit Messages <img src="https://img.icons8.com/dusk/1600/commit-git.png" height="64" /> 
+# Conventional Commit Messages <sub><img src="https://img.icons8.com/dusk/1600/commit-git.png" height="64" /></sub>
 
 See how a [minor change](#examples) to your commit message style can make a difference. 
 

diff --git a/conventional_commit_messages.md b/conventional_commit_messages.md
@@ -1,9 +1,9 @@
-# Conventional Commit Messages 
-See how a [minor change](#examples) to your commit message style can make a difference. 
+# Conventional Commit Messages <img src="https://img.icons8.com/dusk/1600/commit-git.png" height="64" /> 
 
-**ℹ️ [git-conventional-commits](https://github.com/qoomon/git-conventional-commits)**  A CLI util to ensure this conventions and generate changelogs 
+See how a [minor change](#examples) to your commit message style can make a difference. 
 
-<img src="https://img.icons8.com/dusk/1600/commit-git.png" width="200" height="200" />
+> [!TIP]
+> Have a look at **[git-conventional-commits](https://github.com/qoomon/git-conventional-commits)** , a CLI util to ensure these conventions and generate verion and changelogs
 
 ## Commit Message Formats