You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/pull_request_template.md
+27-9Lines changed: 27 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,19 @@ Please fill in the following content to let us know better about this change.
9
9
10
10
## Checklist
11
11
12
-
-[ ] I have read the [contributing guidelines](https://commitizen-tools.github.io/commitizen/contributing/)
12
+
-[ ] I have read the [contributing guidelines](https://commitizen-tools.github.io/commitizen/contributing/contributing)
13
+
14
+
### Was generative AI tooling used to co-author this PR?
15
+
16
+
<!--
17
+
If generative AI tooling has been used in the process of authoring this PR, please change below checkbox to `[X]` followed by the name of the tool, uncomment the "Generated-by".
18
+
-->
19
+
20
+
-[ ] Yes (please specify the tool below)
21
+
22
+
<!--
23
+
Generated-by: [Tool Name] following [the guidelines](http://commitizen-tools.github.io/commitizen/contributing/pull_request/#ai-assisted-contributions)
24
+
-->
13
25
14
26
### Code Changes
15
27
@@ -23,25 +35,31 @@ Please fill in the following content to let us know better about this change.
23
35
-[ ] Update the documentation for the changes
24
36
25
37
### Documentation Changes
38
+
<!-- You can skip this section if you are not making any documentation changes -->
39
+
26
40
27
41
-[ ] Run `uv run poe doc` locally to ensure the documentation pages renders correctly
28
-
-[ ] Check and fix any broken links (internal or external) in the documentation
42
+
-[ ] Check and fix any broken links (internal or external)
29
43
30
-
> When running `uv run poe doc`, any broken internal documentation links will be reported in the console output like this:
31
-
>
32
-
> ```text
33
-
> INFO - Doc file 'config.md' contains a link 'commands/bump.md#-post_bump_hooks', but the doc 'commands/bump.md' does not contain an anchor '#-post_bump_hooks'.
34
-
> ```
44
+
<!--
45
+
When running `uv run poe doc`, any broken internal documentation links will be reported in the console output like this:
46
+
47
+
```text
48
+
INFO - Doc file 'config.md' contains a link 'commands/bump.md#-post_bump_hooks', but the doc 'commands/bump.md' does not contain an anchor '#-post_bump_hooks'.
49
+
```
50
+
-->
35
51
36
52
## Expected Behavior
37
53
<!-- A clear and concise description of what you expected to happen -->
Copy file name to clipboardExpand all lines: docs/README.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -303,6 +303,11 @@ After installation, you can verify the completion is working by:
303
303
304
304
For more detailed information about argcomplete configuration and troubleshooting, visit the [argcomplete documentation](https://kislyuk.github.io/argcomplete/).
305
305
306
+
## Star History
307
+
308
+
[](https://star-history.com/#commitizen-tools/commitizen)
This value can be updated in the configuration file with the key `changelog_file` under `tools.commitizen`
80
+
This value can be updated in the configuration file with the key `changelog_file` under `tool.commitizen`.
81
81
82
-
Specify the name of the output file, remember that changelog only works with Markdown.
82
+
Specify the name of the output file. Note that changelog generation only works with Markdown files.
83
83
84
84
```bash
85
85
cz changelog --file-name="CHANGES.md"
86
86
```
87
87
88
88
### `--incremental`
89
89
90
-
This flag can be set in the configuration file with the key `changelog_incremental` under `tools.commitizen`
90
+
This flag can be set in the configuration file with the key `changelog_incremental` under `tool.commitizen`
91
91
92
92
Benefits:
93
93
94
-
- Build from the latest version found in changelog, this is useful if you have a different changelog and want to use commitizen
94
+
- Build from the latest version found in changelog. This is useful if you have an existing changelog and want to use commitizen to extend it.
95
95
- Update unreleased area
96
-
- Allows users to manually touch the changelog without being rewritten.
96
+
- Allows users to manually edit the changelog without it being completely rewritten.
97
97
98
98
```bash
99
99
cz changelog --incremental
100
100
```
101
101
102
102
```toml
103
-
[tools.commitizen]
103
+
[tool.commitizen]
104
104
# ...
105
105
changelog_incremental = true
106
106
```
107
107
108
108
### `--start-rev`
109
109
110
-
This value can be set in the configuration file with the key `changelog_start_rev` under `tools.commitizen`
110
+
This value can be set in the configuration file with the key `changelog_start_rev` under `tool.commitizen`
111
111
112
112
Start from a given git rev to generate the changelog. Commits before that rev will not be considered. This is especially useful for long-running projects adopting conventional commits, where old commit messages might fail to be parsed for changelog generation.
This flag can be set in the configuration file with the key `changelog_merge_prerelease` under `tools.commitizen`
126
+
This flag can be set in the configuration file with the key `changelog_merge_prerelease` under `tool.commitizen`
127
127
128
-
Collects changes from prereleases into the next non-prerelease. This means that if you have a prerelease version, and then a normal release, the changelog will show the prerelease changes as part of the changes of the normal release. If not set, it will include prereleases in the changelog.
128
+
Collects changes from prereleases into the next non-prerelease version. If you have a prerelease version followed by a normal release, the changelog will show the prerelease changes as part of the normal release. If not set, prereleases will be included as separate entries in the changelog.
129
129
130
130
```bash
131
131
cz changelog --merge-prerelease
132
132
```
133
133
134
134
```toml
135
-
[tools.commitizen]
135
+
[tool.commitizen]
136
136
# ...
137
137
changelog_merge_prerelease = true
138
138
```
139
139
140
140
### `--template`
141
141
142
-
Provides your own changelog jinja template by using the `template` settings or the `--template` parameter.
142
+
Provide your own changelog Jinja template by using the `template` settings or the `--template` parameter.
143
+
144
+
```bash
145
+
cz changelog --template="path/to/template.j2"
146
+
```
143
147
144
148
### `--unreleased-version`
145
149
146
-
There is usually a chicken and egg situation when automatically
147
-
bumping the version and creating the changelog.
148
-
If you bump the version first, you have no changelog, you have to
149
-
create it later, and it won't be included in
150
-
the release of the created version.
150
+
There is usually a chicken-and-egg situation when automatically bumping the version and creating the changelog:
151
151
152
-
If you create the changelog before bumping the version, then you
153
-
usually don't have the latest tag, and the _Unreleased_ title appears.
152
+
-If you bump the version first, you have no changelog yet, and it won't be included in the release of the created version.
153
+
- If you create the changelog before bumping the version, you usually don't have the latest tag, and the _Unreleased_ title appears.
154
154
155
-
By introducing`--unreleased-version` you can prevent this situation.
155
+
By using`--unreleased-version`, you can prevent this situation.
156
156
157
157
Before bumping you can run:
158
158
159
159
```bash
160
160
cz changelog --unreleased-version="v1.0.0"
161
161
```
162
162
163
-
Remember to use the tag instead of the raw version number
163
+
Remember to use the tag format instead of the raw version number.
164
164
165
-
For example if the format of your tag includes a `v` (`v1.0.0`), then you should use that,
166
-
if your tag is the same as the raw version, then ignore this.
165
+
For example, if your tag format includes a `v` prefix (e.g., `v1.0.0`), use that format. If your tag is the same as the raw version (e.g., `1.0.0`), use the raw version.
167
166
168
-
Alternatively you can directly bump the version and create the changelog by doing
167
+
Alternatively, you can directly bump the version and create the changelog by running:
169
168
170
169
```bash
171
170
cz bump --changelog
@@ -175,7 +174,7 @@ cz bump --changelog
175
174
176
175
Supported hook methods:
177
176
178
-
- Per parsed message: Useful to add links
177
+
- Per parsed message: Useful to add links to commits or issues
179
178
- End of changelog generation: Useful to send Slack or chat messages, or notify another department
180
179
181
180
Read more about hooks in the [customization page][customization]
Copy file name to clipboardExpand all lines: docs/contributing/contributing.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
-
##Contributing to Commitizen
1
+
# Contributing to Commitizen
2
2
3
3
First, thank you for taking the time to contribute! 🎉 Your contributions help make Commitizen better for everyone.
4
4
5
5
When contributing to Commitizen, we encourage you to:
6
6
7
-
1. First, check out the [issues](https://github.com/commitizen-tools/commitizen/issues) and [Features we won't add](features_wont_add.md) to see if there's already a discussion about the change you wish to make.
7
+
1. First, check out the [issues](https://github.com/commitizen-tools/commitizen/issues) and [Features we won't add](../features_wont_add.md) to see if there's already a discussion about the change you wish to make.
8
8
2. If there's no discussion, [create an issue](https://github.com/commitizen-tools/commitizen/issues/new) to discuss your proposed changes.
9
9
3. Follow our [development workflow](#development-workflow) and guidelines below.
This document outlines important guidelines to follow when creating a pull request.
4
+
5
+
## Before Creating a Pull Request
6
+
7
+
1.**Check Existing Issues**: Ensure there's a related issue or discussion for your changes. If not, create one first to discuss the proposed changes.
8
+
2.**Follow the Development Workflow**: Make sure you've followed all steps in the [contributing guidelines](contributing.md).
9
+
10
+
## Making Changes
11
+
12
+
When adding new code, match the existing coding style in the file you're modifying. Consistency within a file and throughout the project is crucial for maintainability.
13
+
14
+
## Following PR Description Template Instructions
15
+
16
+
The PR description template includes a checklist and specific requirements. Please:
17
+
18
+
1.**Complete the Checklist**: Check off all applicable items before requesting review.
19
+
2.**Provide Clear Descriptions**: Clearly describe what the change does, expected behavior, and steps to test.
20
+
3.**Respond to Feedback**: Carefully read maintainer feedback and address all points raised. Ask for clarification if something is unclear.
21
+
22
+
## AI-Assisted Contributions
23
+
24
+
We welcome contributions that use AI tools for assistance, but we have strict quality standards to maintain code quality and avoid "AI spaghetti code."
25
+
26
+
!!! note
27
+
Most of our new documentation changes are, of course, generated by AI, but we still need to review it and make sure it's correct.
28
+
29
+
30
+
31
+
### Guidelines for AI-Assisted PRs
32
+
33
+
1.**Review and Refine**: Thoroughly review and understand all AI-generated code. Refactor to match our project's style and remove unnecessary complexity.
34
+
2.**Test Thoroughly**: Don't assume AI-generated code works—test it extensively with comprehensive test cases and manual testing when possible.
35
+
3.**Understand the Code**: You should be able to explain every line. If you don't understand something, learn about it or rewrite it. Maintainers may ask you to explain your code.
36
+
4.**Avoid Common Pitfalls**:
37
+
- Over-engineering (simplify when possible)
38
+
- Inconsistent style (ensure consistency with our standards)
39
+
- Unnecessary dependencies
40
+
- Copy-paste without adaptation
41
+
- Verbose or obvious comments
42
+
5.**Code Quality Still Matters**: AI assistance doesn't excuse poor code quality. All code must pass linting, type checking, and follow best practices.
43
+
6.**Be Transparent**: **Mention AI assistance in the PR description**. Code quality standards remain the same regardless of how the code was written.
44
+
45
+
!!! warning "Consequences of Poor AI-Assisted Contributions"
46
+
Maintainers who identify low-quality AI-generated code or copy-pasted responses will have no choice but to close the related PRs. This adds unnecessary burden on maintainers and doesn't help the project. Additionally, the contributor's reputation is impacted as maintainers may lose confidence and might restrict the user from making further contributions.
47
+
48
+
### What We Consider "AI Spaghetti"
49
+
50
+
Red flags that may result in PR rejection or requests for significant refactoring:
51
+
52
+
- Overly complex solutions when simpler ones exist
53
+
- Unnecessary abstractions or design patterns
54
+
- Code that's difficult to understand or maintain
55
+
- Missing or inadequate tests
56
+
- Copy-pasted code blocks that don't fit the project structure
57
+
- Excessive comments explaining obvious things
58
+
59
+
**Remember**: If you use AI tools, you're still responsible for the quality of the final code. Use AI as a starting point, not a final solution.
60
+
61
+
## Commenting on the PR
62
+
63
+
When commenting on the PR:
64
+
65
+
- Address the feedback points raised by maintainers
66
+
- Ask questions if something is unclear
67
+
-**Do not** just copy-paste AI-generated responses
68
+
- Maintainers want to see your thought process and understanding of the codebase
69
+
- Maintainers and other contributors can tell if you're just copying and pasting AI-generated responses
0 commit comments