diff --git a/scripts/interpreter/gen_commit.py b/scripts/interpreter/gen_commit.py index a4817c4..5139b33 100755 --- a/scripts/interpreter/gen_commit.py +++ b/scripts/interpreter/gen_commit.py @@ -40,7 +40,7 @@ def gen_commit(project_path): agent = OpenInterpreter() agent.auto_run = True with open( - os.path.join(os.path.dirname(__file__), "resources/commit_convention.txt"), + os.path.join(os.path.dirname(__file__), "resources/commit_convention.md"), "r", ) as f: file_content = f.read() diff --git a/scripts/interpreter/resources/commit_convention.md b/scripts/interpreter/resources/commit_convention.md new file mode 100644 index 0000000..6474983 --- /dev/null +++ b/scripts/interpreter/resources/commit_convention.md @@ -0,0 +1,127 @@ +# Conventional Commit Messages + +See how [a minor change](#examples) to your commit message style can make a difference. + +> [!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 +
+<type>(<optional scope>): <description>
+empty separator line
+<optional body>
+empty separator line
+<optional footer>
+
+ +### Merge Commit +
+Merge branch '<branch name>'
+
+Follows default git merge message + +### Revert Commit +
+Revert "<reverted commit subject line>"
+
+Follows default git revert message + +### Inital Commit +``` +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` + +### 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 + +### 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) + +### Description +The `description` contains a concise description of the change. +- 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 + +### 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 + +### 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 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** + - **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 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 . + ``` +- ``` + 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 + ``` + diff --git a/scripts/interpreter/resources/commit_convention.txt b/scripts/interpreter/resources/commit_convention.txt deleted file mode 100644 index f8765dc..0000000 --- a/scripts/interpreter/resources/commit_convention.txt +++ /dev/null @@ -1,50 +0,0 @@ -Git Commit Guidelines -Git Commit -This documented was extracted from Contributing to AngularJS. Every contributor to the project should be aware of the following rules. - -We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the theme framework change log. - -The commit message formatting can be added using a typical git workflow or through the use of a CLI wizard (Commitizen). To use the wizard, run npm run commit in your terminal after staging your changes in git. - -Commit Message Format -Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject: - -(): - - - -