jordan-chisl · November 29, 2024 04:35 · Nov 29, 2024 · Sep 6, 2024 · Sep 6, 2024 · Sep 6, 2024
diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -26,7 +26,7 @@ Revert "<b>&lt;reverted commit subject line&gt;</b>"
 </pre>
 <sup>Follows default git revert message</sup>
 
-### Inital Commit 
+### Initial Commit 
 ```
 init
 ```

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -38,6 +38,7 @@ init
 * `refactor` commits rewrite/restructure your code but does not change any API behaviour
     * `perf` commits are special `refactor` commits that are specific to performance optimisations
 * `model` commits commit code related to data model changes
+* `db` commits add or update code related to database operations
 * `config` commits add or update configuration files (e.g., JSON, YAML, and ENV config files)
 * `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
 * `test` commits add testing code or correct existing tests

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -42,7 +42,7 @@ init
 * `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
 * `test` commits add testing code or correct existing tests
 * `docs` commits affect documentation only
-* `build` commits affect build components (build tools, ci pipeline, dependencies, project version, etc.)
+* `build` commits affect build components (build tools, CI pipeline, dependencies, project version, etc.)
 * `ops` commits affect operational components (infrastructure, deployment, backup, recovery, etc.)
 * `chore` commits are miscellaneous commits e.g. modifying `.gitignore`
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -37,7 +37,7 @@ init
     * `fix` commits fix a bug
 * `refactor` commits rewrite/restructure your code but does not change any API behaviour
     * `perf` commits are special `refactor` commits that are specific to performance optimisations
-* `model` commits add or change data models
+* `model` commits commit code related to data model changes
 * `config` commits add or update configuration files (e.g., JSON, YAML, and ENV config files)
 * `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
 * `test` commits add testing code or correct existing tests

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -37,6 +37,7 @@ init
     * `fix` commits fix a bug
 * `refactor` commits rewrite/restructure your code but does not change any API behaviour
     * `perf` commits are special `refactor` commits that are specific to performance optimisations
+* `model` commits add or change data models
 * `config` commits add or update configuration files (e.g., JSON, YAML, and ENV config files)
 * `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
 * `test` commits add testing code or correct existing tests

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -5,7 +5,7 @@ A commit message guideline based on the **[Conventional Commits Specification](h
 
 ## Commit Message Formats
 
-### Default
+### Standard 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
@@ -46,11 +46,10 @@ init
 * `chore` commits are miscellaneous commits e.g. modifying `.gitignore`
 
 ### Scope (Optional)
-The `scope` provides additional contextual information about the commit, such as a one-word description of a section of the codebase (e.g., `fix(parser):`).
+The `scope` provides additional contextual information about the commit, such as a few descriptive words refering to a section of the codebase (e.g., `fix(parser):`).
 * It is an **optional** part of the format
 * Allowed scopes depends on the specific project
 * Don't use issue identifiers as scopes
-* In most cases the scope should be a one-word noun
 
 ### Breaking Changes Indicator (Optional)
 Breaking changes should be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -119,85 +119,4 @@ The `footer` should contain any information about breaking changes and is also t
   ```
 
 ---
-
-## Git Hook Scripts to ensure commit message header format
-
-### 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
-
-### pre-receive Hook (server side)
-* create following file in your repository folder `.git/hooks/pre-receive`
-  ```shell
-  #!/usr/bin/env bash
-
-  # Pre-receive hook that will block commits with messges 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'`)
-
------
-## 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
-<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
 
diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -82,14 +82,14 @@ The `footer` should contain any information about breaking changes and is also t
   feat: add email notifications on new direct messages
   ```
 * ```
-  feat(shopping cart): add the amazing button
+  feat(shopping cart): add the checkout button
   ```
 * ```
   feat!: remove ticket list endpoint
 
-  refers to JIRA-1337
+  refer to JIRA-1337
 
-  BREAKING CHANGES: ticket enpoints no longer supports list all entites.
+  BREAKING CHANGES: ticket endpoints no longer support list all entities
   ```
 * ```
   fix(api): handle empty message in request body

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -37,6 +37,7 @@ init
     * `fix` commits fix a bug
 * `refactor` commits rewrite/restructure your code but does not change any API behaviour
     * `perf` commits are special `refactor` commits that are specific to performance optimisations
+* `config` commits add or update configuration files (e.g., JSON, YAML, and ENV config files)
 * `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
 * `test` commits add testing code or correct existing tests
 * `docs` commits affect documentation only

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
 
 A commit message guideline based on the **[Conventional Commits Specification](https://www.conventionalcommits.org/en/v1.0.0/#specification)**.
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -51,7 +51,7 @@ The `scope` provides additional contextual information about the commit, such as
 * Don't use issue identifiers as scopes
 * In most cases the scope should be a one-word noun
 
-### Breaking Changes Indicator
+### Breaking Changes Indicator (Optional)
 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
 
@@ -63,13 +63,13 @@ The `description` contains a concise description of the change.
 * Don't capitalize the first letter
 * No period (`.`) at the end
 
-### Body
+### Body (Optional)
 The `body` should include the motivation for the change and contrast this with previous behavior.
 * It 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
+### Footer (Optional)
 The `footer` should contain any information about breaking changes and is also the place to reference issues that this commit refers to.
 * It is an **optional** part of the format
 * **Optionally** reference an issue by its id.

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -65,15 +65,15 @@ The `description` contains a concise description of the change.
 
 ### Body
 The `body` should include the motivation for the change and contrast this with previous behavior.
-* Is an **optional** part of the format
+* It 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.
+The `footer` should contain any information about breaking changes and is also the place to reference issues that this commit refers to.
+* It 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.
 
 
 ### Examples

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -57,11 +57,11 @@ 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
-* No dot (`.`) at the end
+* No period (`.`) at the end
 
 ### 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
@@ -45,7 +45,7 @@ init
 * `chore` commits are miscellaneous commits e.g. modifying `.gitignore`
 
 ### Scope (Optional)
-The `scope` provides additional contextual information about the commit, such as a one-word description of a section of the codebase (e.g., `fix(parser):)`.
+The `scope` provides additional contextual information about the commit, such as a one-word description of a section of the codebase (e.g., `fix(parser):`).
 * It is an **optional** part of the format
 * Allowed scopes depends on the specific project
 * Don't use issue identifiers as scopes

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -45,7 +45,7 @@ init
 * `chore` commits are miscellaneous commits e.g. modifying `.gitignore`
 
 ### Scope (Optional)
-The `scope` provides additional contextual information about the commit, such as a one-word description of a section of the codebase (e.g., `fix(parser):`.
+The `scope` provides additional contextual information about the commit, such as a one-word description of a section of the codebase (e.g., `fix(parser):)`.
 * It is an **optional** part of the format
 * Allowed scopes depends on the specific project
 * Don't use issue identifiers as scopes

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -44,11 +44,12 @@ init
 * `ops` commits affect operational components (infrastructure, deployment, backup, recovery, etc.)
 * `chore` commits are miscellaneous commits e.g. modifying `.gitignore`
 
-### Scopes
-The `scope` provides additional contextual information.
-* Is an **optional** part of the format
-* Allowed Scopes depends on the specific project
+### Scope (Optional)
+The `scope` provides additional contextual information about the commit, such as a one-word description of a section of the codebase (e.g., `fix(parser):`.
+* It is an **optional** part of the format
+* Allowed scopes depends on the specific project
 * Don't use issue identifiers as scopes
+* In most cases the scope should be a one-word noun
 
 ### Breaking Changes Indicator
 Breaking changes should be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -2,8 +2,6 @@
 
 A commit message guideline based on the **[Conventional Commits Specification](https://www.conventionalcommits.org/en/v1.0.0/#specification)**.
 
-<a href="https://www.conventionalcommits.org/en/v1.0.0/#specification" target="blank">Conventional Commits</a>
-
 
 ## Commit Message Formats
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -2,7 +2,7 @@
 
 A commit message guideline based on the **[Conventional Commits Specification](https://www.conventionalcommits.org/en/v1.0.0/#specification)**.
 
-<a href="https://www.conventionalcommits.org/en/v1.0.0/#specification" target="_blank">Conventional Commits</a>
+<a href="https://www.conventionalcommits.org/en/v1.0.0/#specification" target="blank">Conventional Commits</a>
 
 
 ## Commit Message Formats

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -2,6 +2,9 @@
 
 A commit message guideline based on the **[Conventional Commits Specification](https://www.conventionalcommits.org/en/v1.0.0/#specification)**.
 
+<a href="https://www.conventionalcommits.org/en/v1.0.0/#specification" target="_blank">Conventional Commits</a>
+
+
 ## Commit Message Formats
 
 ### Default

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -1,9 +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. 
-
-> [!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
+A commit message guideline based on the **[Conventional Commits Specification](https://www.conventionalcommits.org/en/v1.0.0/#specification)**.
 
 ## Commit Message Formats
 

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -37,7 +37,7 @@ init
 * API relevant changes
     * `feat` commits add or remove a new feature
     * `fix` commits fix a bug
-* `refactor` commits rewrite/restructure your code, however does not change any API behaviour
+* `refactor` commits rewrite/restructure your code but does not change any API behaviour
     * `perf` commits are special `refactor` commits that are specific to performance optimisations
 * `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
 * `test` commits add testing code or correct existing tests

diff --git a/conventional-commits-cheatsheet.md b/conventional-commits-cheatsheet.md
@@ -35,16 +35,16 @@ init
 
 ### Types
 * API relevant changes
-    * `feat` Commits, that adds or remove a new feature
-    * `fix` Commits, that fixes a bug
-* `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`
+    * `feat` commits add or remove a new feature
+    * `fix` commits fix a bug
+* `refactor` commits rewrite/restructure your code, however does not change any API behaviour
+    * `perf` commits are special `refactor` commits that are specific to performance optimisations
+* `style` commits do not affect the meaning of the existing code (whitespace, formatting, missing semi-colons, etc.)
+* `test` commits add testing code or correct existing tests
+* `docs` commits affect documentation only
+* `build` commits affect build components (build tools, ci pipeline, dependencies, project version, etc.)
+* `ops` commits affect operational components (infrastructure, deployment, backup, recovery, etc.)
+* `chore` commits are miscellaneous commits e.g. modifying `.gitignore`
 
 ### Scopes
 The `scope` provides additional contextual information.

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