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
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]
0 commit comments