commitizen/docs/customization.md at master * rockleona/commitizen * GitHub

Customizing commitizen is not hard at all. We have two different ways to do so.

1. Customize in configuration file

The basic steps are:

Define your custom committing or bumping rules in the configuration file.
Declare name = "cz_customize" in your configuration file, or add -n cz_customize when running commitizen.

Example:

[tool.commitizen] name = "cz_customize" [tool.commitizen.customize] message_template = "{{change_type}}:{% if show_message %} {{message}}{% endif %}" example = "feature: this feature enable customize through config file" schema = ": " schema_pattern = "(feature|bug fix):(\\s.*)" bump_pattern = "^(break|new|fix|hotfix)" bump_map = {"break" = "MAJOR", "new" = "MINOR", "fix" = "PATCH", "hotfix" = "PATCH"} change_type_order = ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"] info_path = "cz_customize_info.txt" info = """ This is customized info """ commit_parser = "^(?Pfeature|bug fix):\\s(?P.*)?" changelog_pattern = "^(feature|bug fix)?(!)?" change_type_map = {"feature" = "Feat", "bug fix" = "Fix"} [[tool.commitizen.customize.questions]] type = "list" name = "change_type" choices = [{value = "feature", name = "feature: A new feature."}, {value = "bug fix", name = "bug fix: A bug fix."}] # choices = ["feature", "fix"] # short version message = "Select the type of change you are committing" [[tool.commitizen.customize.questions]] type = "input" name = "message" message = "Body." [[tool.commitizen.customize.questions]] type = "confirm" name = "show_message" message = "Do you want to add body message in commit?"

The equivalent example for a json config file:

{ "commitizen": { "name": "cz_customize", "customize": { "message_template": "{{change_type}}:{% if show_message %} {{message}}{% endif %}", "example": "feature: this feature enable customize through config file", "schema": ": ", "schema_pattern": "(feature|bug fix):(\\s.*)", "bump_pattern": "^(break|new|fix|hotfix)", "bump_map": { "break": "MAJOR", "new": "MINOR", "fix": "PATCH", "hotfix": "PATCH" }, "change_type_order": ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"], "info_path": "cz_customize_info.txt", "info": "This is customized info", "commit_parser": "^(?Pfeature|bug fix):\\s(?P.*)?", "changelog_pattern": "^(feature|bug fix)?(!)?", "change_type_map": {"feature": "Feat", "bug fix": "Fix"}, "questions": [ { "type": "list", "name": "change_type", "choices": [ { "value": "feature", "name": "feature: A new feature." }, { "value": "bug fix", "name": "bug fix: A bug fix." } ], "message": "Select the type of change you are committing" }, { "type": "input", "name": "message", "message": "Body." }, { "type": "confirm", "name": "show_message", "message": "Do you want to add body message in commit?" } ] } } }

And the correspondent example for a yaml json file:

: " schema_pattern: "(feature|bug fix):(\\s.*)" bump_pattern: "^(break|new|fix|hotfix)" commit_parser: "^(?Pfeature|bug fix):\\s(?P.*)?", changelog_pattern: "^(feature|bug fix)?(!)?", change_type_map: feature: Feat bug fix: Fix bump_map: break: MAJOR new: MINOR fix: PATCH hotfix: PATCH change_type_order: ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"] info_path: cz_customize_info.txt info: This is customized info questions: - type: list name: change_type choices: - value: feature name: 'feature: A new feature.' - value: bug fix name: 'bug fix: A bug fix.' message: Select the type of change you are committing - type: input name: message message: Body. - type: confirm name: show_message message: Do you want to add body message in commit?">commitizen: name: cz_customize customize: message_template: "{{change_type}}:{% if show_message %} {{message}}{% endif %}" example: 'feature: this feature enable customize through config file' schema: ": " schema_pattern: "(feature|bug fix):(\\s.*)" bump_pattern: "^(break|new|fix|hotfix)" commit_parser: "^(?Pfeature|bug fix):\\s(?P.*)?", changelog_pattern: "^(feature|bug fix)?(!)?", change_type_map: feature: Feat bug fix: Fix bump_map: break: MAJOR new: MINOR fix: PATCH hotfix: PATCH change_type_order: ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"] info_path: cz_customize_info.txt info: This is customized info questions: - type: list name: change_type choices: - value: feature name: 'feature: A new feature.' - value: bug fix name: 'bug fix: A bug fix.' message: Select the type of change you are committing - type: input name: message message: Body. - type: confirm name: show_message message: Do you want to add body message in commit?

Customize configuration

Parameter	Type	Default	Description
`questions`	`Questions`	`None`	Questions regarding the commit message. Detailed below. The type `Questions` is an alias to `Iterable[MutableMapping[str, Any]]` which is defined in `commitizen.defaults`. It expects a list of dictionaries.
`message_template`	`str`	`None`	The template for generating message from the given answers. `message_template` should either follow Jinja2 formatting specification, and all the variables in this template should be defined in `name` in `questions`
`example`	`str`	`None`	(OPTIONAL) Provide an example to help understand the style. Used by `cz example`.
`schema`	`str`	`None`	(OPTIONAL) Show the schema used. Used by `cz schema`.
`schema_pattern`	`str`	`None`	(OPTIONAL) The regular expression used to do commit message validation. Used by `cz check`.
`info_path`	`str`	`None`	(OPTIONAL) The path to the file that contains explanation of the commit rules. Used by `cz info`. If not provided `cz info`, will load `info` instead.
`info`	`str`	`None`	(OPTIONAL) Explanation of the commit rules. Used by `cz info`.
`bump_map`	`dict`	`None`	(OPTIONAL) Dictionary mapping the extracted information to a `SemVer` increment type (`MAJOR`, `MINOR`, `PATCH`)
`bump_pattern`	`str`	`None`	(OPTIONAL) Regex to extract information from commit (subject and body)
`change_type_order`	`str`	`None`	(OPTIONAL) List of strings used to order the Changelog. All other types will be sorted alphabetically. Default is `["BREAKING CHANGE", "Feat", "Fix", "Refactor", "Perf"]`
`commit_parser`	`str`	`None`	(OPTIONAL) Regex to extract information used in creating changelog. See more
`changelog_pattern`	`str`	`None`	(OPTIONAL) Regex to understand which commits to include in the changelog
`change_type_map`	`dict`	`None`	(OPTIONAL) Dictionary mapping the type of the commit to a changelog entry

Detailed `questions` content

Parameter	Type	Default	Description
`type`	`str`	`None`	The type of questions. Valid type: `list`, `input` and etc. [See More][different-question-types]
`name`	`str`	`None`	The key for the value answered by user. It's used in `message_template`
`message`	`str`	`None`	Detail description for the question.
`choices`	`list`	`None`	(OPTIONAL) The choices when `type = list`. Either use a list of values or a list of dictionaries with `name` and `value` keys. Keyboard shortcuts can be defined via `key`. See examples above.
`default`	`Any`	`None`	(OPTIONAL) The default value for this question.
`filter`	`str`	`None`	(Optional) Validator for user's answer. (Work in Progress)
[different-question-types]: https://github.com/tmbo/questionary#different-question-types

Shortcut keys

When the use_shortcuts config option is enabled, commitizen can show and use keyboard shortcuts to select items from lists directly. For example, when using the cz_conventional_commits commitizen template, shortcut keys are shown when selecting the commit type. Unless otherwise defined, keyboard shortcuts will be numbered automatically. To specify keyboard shortcuts for your custom choices, provide the shortcut using the key parameter in dictionary form for each choice you would like to customize.

2. Customize through customizing a class

The basic steps are:

Inheriting from BaseCommitizen
Give a name to your rules.
Create a python package using setup.py, poetry, etc
Expose the class as a commitizen.plugin entrypoint

Check an example on how to configure BaseCommitizen.

You can also automate the steps above through cookiecutter.

cookiecutter gh:commitizen-tools/commitizen_cz_template

See commitizen_cz_template for details.

Once you publish your rules, you can send us a PR to the Third-party section.

Custom commit rules

Create a Python module, for example cz_jira.py.

Inherit from BaseCommitizen, and you must define questions and message. The others are optional.

from commitizen.cz.base import BaseCommitizen from commitizen.defaults import Questions class JiraCz(BaseCommitizen): # Questions = Iterable[MutableMapping[str, Any]] # It expects a list with dictionaries. def questions(self) -> Questions: """Questions regarding the commit message.""" questions = [ {"type": "input", "name": "title", "message": "Commit title"}, {"type": "input", "name": "issue", "message": "Jira Issue number:"}, ] return questions def message(self, answers: dict) -> str: """Generate the message with the given answers.""" return "{0} (#{1})".format(answers["title"], answers["issue"]) def example(self) -> str: """Provide an example to help understand the style (OPTIONAL) Used by `cz example`. """ return "Problem with user (#321)" def schema(self) -> str: """Show the schema used (OPTIONAL) Used by `cz schema`. """ return " (<issue>)"</span><br><br> <span>def</span> <span>info</span>(<span>self</span>) <span>-></span> <span>str</span>:<br> <span>"""Explanation of the commit rules. (OPTIONAL)</span><br><span></span><br><span> Used by `cz info`.</span><br><span> """</span><br> <span>return</span> <span>"We use this because is useful"</span></tt></div> <p dir="auto">The next file required is <code>setup.py</code> modified from flask version.</p> <div dir="auto"><tt><span>from</span> <span>setuptools</span> <span>import</span> <span>setup</span><br><br><span>setup</span>(<br> <span>name</span><span>=</span><span>"JiraCommitizen"</span>,<br> <span>version</span><span>=</span><span>"0.1.0"</span>,<br> <span>py_modules</span><span>=</span>[<span>"cz_jira"</span>],<br> <span>license</span><span>=</span><span>"MIT"</span>,<br> <span>long_description</span><span>=</span><span>"this is a long description"</span>,<br> <span>install_requires</span><span>=</span>[<span>"commitizen"</span>],<br> <span>entry_points</span><span>=</span>{<span>"commitizen.plugin"</span>: [<span>"cz_jira = cz_jira:JiraCz"</span>]},<br>)</tt></div> <p dir="auto">So in the end, we would have</p> <div><tt><code>.<br>+-- cz_jira.py<br>+-- setup.py<br></code></tt></div> <p dir="auto">And that's it. You can install it without uploading to pypi by simply doing <code>pip install .</code></p> <p dir="auto">If you feel like it should be part of this repo, create a PR.</p> <div dir="auto"><h3 tabindex="-1" dir="auto">Custom bump rules</h3></div> <p dir="auto">You need to define 2 parameters inside your custom <code>BaseCommitizen</code>.</p> <markdown-accessiblity-table><table> <thead> <tr> <th>Parameter</th> <th>Type</th> <th>Default</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td><code>bump_pattern</code></td> <td><code>str</code></td> <td><code>None</code></td> <td>Regex to extract information from commit (subject and body)</td> </tr> <tr> <td><code>bump_map</code></td> <td><code>dict</code></td> <td><code>None</code></td> <td>Dictionary mapping the extracted information to a <code>SemVer</code> increment type (<code>MAJOR</code>, <code>MINOR</code>, <code>PATCH</code>)</td> </tr> </tbody> </table></markdown-accessiblity-table> <p dir="auto">Let's see an example.</p> <div dir="auto"><tt><span>from</span> <span>commitizen</span>.<span>cz</span>.<span>base</span> <span>import</span> <span>BaseCommitizen</span><br><br><br><span>class</span> <span>StrangeCommitizen</span>(<span>BaseCommitizen</span>):<br> <span>bump_pattern</span> <span>=</span> <span>r"^(break|new|fix|hotfix)"</span><br> <span>bump_map</span> <span>=</span> {<span>"break"</span>: <span>"MAJOR"</span>, <span>"new"</span>: <span>"MINOR"</span>, <span>"fix"</span>: <span>"PATCH"</span>, <span>"hotfix"</span>: <span>"PATCH"</span>}</tt></div> <p dir="auto">That's it, your commitizen now supports custom rules, and you can run.</p> <div dir="auto"><tt>cz -n cz_strange bump</tt></div> <div dir="auto"><h3 tabindex="-1" dir="auto">Custom changelog generator</h3></div> <p dir="auto">The changelog generator should just work in a very basic manner without touching anything. You can customize it of course, and this are the variables you need to add to your custom <code>BaseCommitizen</code>.</p> <markdown-accessiblity-table><table> <thead> <tr> <th>Parameter</th> <th>Type</th> <th>Required</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td><code>commit_parser</code></td> <td><code>str</code></td> <td>NO</td> <td>Regex which should provide the variables explained in the <a href="/github.com/rockleona/commitizen/blob/master/docs/changelog.md#description">changelog description</a></td> </tr> <tr> <td><code>changelog_pattern</code></td> <td><code>str</code></td> <td>NO</td> <td>Regex to validate the commits, this is useful to skip commits that don't meet your ruling standards like a Merge. Usually the same as bump_pattern</td> </tr> <tr> <td><code>change_type_map</code></td> <td><code>dict</code></td> <td>NO</td> <td>Convert the title of the change type that will appear in the changelog, if a value is not found, the original will be provided</td> </tr> <tr> <td><code>changelog_message_builder_hook</code></td> <td>`method: (dict, git.GitCommit) -> dict</td> <td>list</td> <td>None`</td> </tr> <tr> <td><code>changelog_hook</code></td> <td><code>method: (full_changelog: str, partial_changelog: Optional[str]) -> str</code></td> <td>NO</td> <td>Receives the whole and partial (if used incremental) changelog. Useful to send slack messages or notify a compliance department. Must return the full_changelog</td> </tr> <tr> <td><code>changelog_release_hook</code></td> <td><code>method: (release: dict, tag: git.GitTag) -> dict</code></td> <td>NO</td> <td>Receives each generated changelog release and its associated tag. Useful to enrich a releases before they are rendered. Must return the update release</td> </tr> </tbody> </table></markdown-accessiblity-table> <div dir="auto"s the output about to being written into the file partial_changelog: it's the new stuff, this is useful to send slack messages or similar Return: the new updated full_changelog """ if partial_changelog: chat.room("#committers").notify(partial_changelog) if full_changelog: compliance.send(full_changelog) full_changelog.replace(" fix ", " **fix** ") return full_changelog"><tt><span>from</span> <span>commitizen</span>.<span>cz</span>.<span>base</span> <span>import</span> <span>BaseCommitizen</span><br><span>import</span> <span>chat</span><br><span>import</span> <span>compliance</span><br><br><br><span>class</span> <span>StrangeCommitizen</span>(<span>BaseCommitizen</span>):<br> <span>changelog_pattern</span> <span>=</span> <span>r"^(break|new|fix|hotfix)"</span><br> <span>commit_parser</span> <span>=</span> <span>r"^(?P<change_type>feat|fix|refactor|perf|BREAKING CHANGE)(?:\((?P<scope>[^()\r\n]*)\)|\()?(?P<breaking>!)?:\s(?P<message>.*)?"</span><br> <span>change_type_map</span> <span>=</span> {<br> <span>"feat"</span>: <span>"Features"</span>,<br> <span>"fix"</span>: <span>"Bug Fixes"</span>,<br> <span>"refactor"</span>: <span>"Code Refactor"</span>,<br> <span>"perf"</span>: <span>"Performance improvements"</span>,<br> }<br><br> <span>def</span> <span>changelog_message_builder_hook</span>(<br> <span>self</span>, <span>parsed_message</span>: <span>dict</span>, <span>commit</span>: <span>git</span>.<span>GitCommit</span><br> ) <span>-></span> <span>dict</span> <span>|</span> <span>list</span> <span>|</span> <span>None</span>:<br> <span>rev</span> <span>=</span> <span>commit</span>.<span>rev</span><br> <span>m</span> <span>=</span> <span>parsed_message</span>[<span>"message"</span>]<br> <span>parsed_message</span>[<br> <span>"message"</span><br> ] <span>=</span> <span>f"<span><span>{</span><span>m</span><span>}</span></span> <span><span>{</span><span>rev</span><span>}</span></span> [<span><span>{</span><span>commit</span>.<span>author</span><span>}</span></span>](<span><span>{</span><span>commit</span>.<span>author_email</span><span>}</span></span>)"</span><br> <span>return</span> <span>parsed_message</span><br><br> <span>def</span> <span>changelog_release_hook</span>(<span>self</span>, <span>release</span>: <span>dict</span>, <span>tag</span>: <span>git</span>.<span>GitTag</span>) <span>-></span> <span>dict</span>:<br> <span>release</span>[<span>"author"</span>] <span>=</span> <span>tag</span>.<span>author</span><br> <span>return</span> <span>release</span><br><br> <span>def</span> <span>changelog_hook</span>(<br> <span>self</span>, <span>full_changelog</span>: <span>str</span>, <span>partial_changelog</span>: <span>Optional</span>[<span>str</span>]<br> ) <span>-></span> <span>str</span>:<br> <span>"""Executed at the end of the changelog generation</span><br><span></span><br><span> full_changelog: it's the output about to being written into the file</span><br><span> partial_changelog: it's the new stuff, this is useful to send slack messages or</span><br><span> similar</span><br><span></span><br><span> Return:</span><br><span> the new updated full_changelog</span><br><span> """</span><br> <span>if</span> <span>partial_changelog</span>:<br> <span>chat</span>.<span>room</span>(<span>"#committers"</span>).<span>notify</span>(<span>partial_changelog</span>)<br> <span>if</span> <span>full_changelog</span>:<br> <span>compliance</span>.<span>send</span>(<span>full_changelog</span>)<br> <span>full_changelog</span>.<span>replace</span>(<span>" fix "</span>, <span>" **fix** "</span>)<br> <span>return</span> <span>full_changelog</span></tt></div> <div dir="auto"><h3 tabindex="-1" dir="auto">Raise Customize Exception</h3></div> <p dir="auto">If you want <code>commitizen</code> to catch your exception and print the message, you'll have to inherit <code>CzException</code>.</p> <div dir="auto"><tt><span>from</span> <span>commitizen</span>.<span>cz</span>.<span>exception</span> <span>import</span> <span>CzException</span><br><br><br><span>class</span> <span>NoSubjectProvidedException</span>(<span>CzException</span>):<br> ...</tt></div> <div dir="auto"><h3 tabindex="-1" dir="auto">Migrating from legacy plugin format</h3></div> <p dir="auto">Commitizen migrated to a new plugin format relying on <code>importlib.metadata.EntryPoint</code>. Migration should be straight-forward for legacy plugins:</p> <ul dir="auto"> <li>Remove the <code>discover_this</code> line from you plugin module</li> <li>Expose the plugin class under as a <code>commitizen.plugin</code> entrypoint.</li> </ul> <p dir="auto">The name of the plugin is now determined by the name of the entrypoint.</p> <div dir="auto"><h4 tabindex="-1" dir="auto">Example</h4></div> <p dir="auto">If you were having a <code>CzPlugin</code> class in a <code>cz_plugin.py</code> module like this:</p> <div dir="auto"><tt><span>from</span> <span>commitizen</span>.<span>cz</span>.<span>base</span> <span>import</span> <span>BaseCommitizen</span><br><br><br><span>class</span> <span>PluginCz</span>(<span>BaseCommitizen</span>):<br> ...<br><br><br><span>discover_this</span> <span>=</span> <span>PluginCz</span></tt></div> <p dir="auto">Then remove the <code>discover_this</code> line:</p> <div dir="auto"><tt><span>from</span> <span>commitizen</span>.<span>cz</span>.<span>base</span> <span>import</span> <span>BaseCommitizen</span><br><br><br><span>class</span> <span>PluginCz</span>(<span>BaseCommitizen</span>):<br> ...</tt></div> <p dir="auto">and expose the class as entrypoint in you setuptools:</p> <div dir="auto"><tt><span>from</span> <span>setuptools</span> <span>import</span> <span>setup</span><br><br><span>setup</span>(<br> <span>name</span><span>=</span><span>"MyPlugin"</span>,<br> <span>version</span><span>=</span><span>"0.1.0"</span>,<br> <span>py_modules</span><span>=</span>[<span>"cz_plugin"</span>],<br> <span>entry_points</span><span>=</span>{<span>"commitizen.plugin"</span>: [<span>"plugin = cz_plugin:PluginCz"</span>]},<br> ...,<br>)</tt></div> <p dir="auto">Then your plugin will be available under the name <code>plugin</code>.</p> <div dir="auto"><h2 tabindex="-1" dir="auto">Customizing the changelog template</h2></div> <p dir="auto">Commitizen gives you the possibility to provide your own changelog template, by:</p> <ul dir="auto"> <li>providing one with your customization class</li> <li>providing one from the current working directory and setting it: <ul dir="auto"> <li>as <a href="/github.com/rockleona/commitizen/blob/master/docs/config.md#template">configuration</a></li> <li>as <code>--template</code> parameter to both <code>bump</code> and <code>changelog</code> commands</li> </ul> </li> <li>either by providing a template with the same name as the default template</li> </ul> <p dir="auto">By default, the template used is the <code>CHANGELOG.md.j2</code> file from the commitizen repository.</p> <div dir="auto"><h3 tabindex="-1" dir="auto">Providing a template with your customization class</h3></div> <p dir="auto">There is 3 parameters available to change the template rendering from your custom <code>BaseCommitizen</code>.</p> <markdown-accessiblity-table><table> <thead> <tr> <th>Parameter</th> <th>Type</th> <th>Default</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td><code>template</code></td> <td><code>str</code></td> <td><code>None</code></td> <td>Provide your own template name (default to <code>CHANGELOG.md.j2</code>)</td> </tr> <tr> <td><code>template_loader</code></td> <td><code>str</code></td> <td><code>None</code></td> <td>Override the default template loader (so you can provide template from you customization class)</td> </tr> <tr> <td><code>template_extras</code></td> <td><code>dict</code></td> <td><code>None</code></td> <td>Provide some extra template parameters</td> </tr> </tbody> </table></markdown-accessiblity-table> <p dir="auto">Let's see an example.</p> <div dir="auto"><tt><span>from</span> <span>commitizen</span>.<span>cz</span>.<span>base</span> <span>import</span> <span>BaseCommitizen</span><br><span>from</span> <span>jinja2</span> <span>import</span> <span>PackageLoader</span><br><br><br><span>class</span> <span>MyPlugin</span>(<span>BaseCommitizen</span>):<br> <span>template</span> <span>=</span> <span>"CHANGELOG.md.jinja"</span><br> <span>template_loader</span> <span>=</span> <span>PackageLoader</span>(<span>"my_plugin"</span>, <span>"templates"</span>)<br> <span>template_extras</span> <span>=</span> {<span>"key"</span>: <span>"value"</span>}</tt></div> <p dir="auto">This snippet will:</p> <ul dir="auto"> <li>use <code>CHANGELOG.md.jinja</code> as template name</li> <li>search for it in the <code>templates</code> directory for <code>my_plugin</code> package</li> <li>add the <code>key=value</code> variable in the template</li> </ul> <div dir="auto"><h3 tabindex="-1" dir="auto">Providing a template from the current working directory</h3></div> <p dir="auto">Users can provides their own template from their current working directory (your project root) by:</p> <ul dir="auto"> <li>providing a template with the same name (<code>CHANGELOG.md.j2</code> unless overridden by your custom class)</li> <li>setting your template path as <code>template</code> configuration</li> <li>giving your template path as <code>--template</code> parameter to <code>bump</code> and <code>changelog</code> commands</li> </ul> <p dir="auto">!!! Note The path is relative to the current working directory, aka. your project root most of the time.</p> <div dir="auto"><h3 tabindex="-1" dir="auto">Template variables</h3></div> <p dir="auto">The default template use a single <code>tree</code> variable which is a list of entries (a release) with the following format:</p> <markdown-accessiblity-table><table> <thead> <tr> <th>Name</th> <th>Type</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>version</td> <td><code>str</code></td> <td>The release version</td> </tr> <tr> <td>date</td> <td><code>datetime</code></td> <td>The release date</td> </tr> <tr> <td>changes</td> <td><code>list[tuple[str, list[Change]]]</code></td> <td>The release sorted changes list in the form <code>(type, changes)</code></td> </tr> </tbody> </table></markdown-accessiblity-table> <p dir="auto">Each <code>Change</code> has the following fields:</p> <markdown-accessiblity-table><table> <thead> <tr> <th>Name</th> <th>Type</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>scope</td> <td>`str</td> <td>None`</td> </tr> <tr> <td>message</td> <td><code>str</code></td> <td>The commit message body</td> </tr> <tr> <td>sha1</td> <td><code>str</code></td> <td>The commit <code>sha1</code></td> </tr> <tr> <td>author</td> <td><code>str</code></td> <td>The commit author name</td> </tr> <tr> <td>author_email</td> <td><code>str</code></td> <td>The commit author email</td> </tr> </tbody> </table></markdown-accessiblity-table> <p dir="auto">!!! Note The field values depend on the customization class and/or the settings you provide</p> <p dir="auto">When using another template (either provided by a plugin or by yourself), you can also pass extra template variables by:</p> <ul dir="auto"> <li>defining them in your configuration with the <a href="/github.com/rockleona/commitizen/blob/master/docs/config.md#extras"><code>extras</code> settings</a></li> <li>providing them on the commandline with the <code>--extra/-e</code> parameter to <code>bump</code> and <code>changelog</code> commands</li> </ul> </article></div><button hidden=""></button></section></div></div></div> </div>  </div></div></div></div></div></div><div id="find-result-marks-container"></div><button hidden=""></button><button hidden=""></button></div>   </div> </react-app> </div> </turbo-frame> </main> </div> </div> <footer role="contentinfo" > <h2>Footer</h2> <div> <div> <a href="/github.com"> </a> <span> (c) 2026 GitHub, Inc. </span> </div> <nav aria-label="Footer"> <h3 id="sr-footer-heading">Footer navigation</h3> <ul aria-labelledby="sr-footer-heading"> <li> <a href="/docs.github.com/site-policy/github-terms/github-terms-of-service">Terms</a> </li> <li> <a href="/docs.github.com/site-policy/privacy-policies/github-privacy-statement">Privacy</a> </li> <li> <a href="/github.com/security">Security</a> </li> <li> <a href="/www.githubstatus.com/">Status</a> </li> <li> <a href="/github.community/">Community</a> </li> <li> <a href="/docs.github.com/">Docs</a> </li> <li> <a href="/support.github.com?tags=dotcom-footer">Contact</a> </li> <li > <cookie-consent-link> <button type="button" > Manage cookies </button> </cookie-consent-link> </li> <li> <cookie-consent-link> <button type="button" > Do not share my personal information </button> </cookie-consent-link> </li> </ul> </nav> </div> </footer> <ghcc-consent id="ghcc" ></ghcc-consent> <div id="ajax-error-message" hidden> <button type="button" aria-label="Dismiss error"> </button> You can't perform that action at this time. </div> <template id="site-details-dialog"> <details open> <summary role="button" aria-label="Close dialog"></summary> <details-dialog> <button type="button" aria-label="Close dialog" data-close-dialog> </button> <div></div> </details-dialog> </details> </template> <div> <div> </div> </div> <template id="snippet-clipboard-copy-button"> <div> <clipboard-copy aria-label="Copy"> </clipboard-copy> </div> </template> <template id="snippet-clipboard-copy-button-unpositioned"> <div> <clipboard-copy aria-label="Copy"> </clipboard-copy> </div> </template> </div> <div id="js-global-screen-reader-notice" aria-live="polite" aria-atomic="true" ></div> <div id="js-global-screen-reader-notice-assertive" aria-live="assertive" aria-atomic="true"></div> </body> </html>

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

customization.md

Latest commit

History

customization.md

File metadata and controls

1. Customize in configuration file

Customize configuration

Detailed `questions` content

Shortcut keys

2. Customize through customizing a class

Custom commit rules

FilesExpand file tree

customization.md

Latest commit

History

customization.md

File metadata and controls

1. Customize in configuration file

Customize configuration

Detailed questions content

Shortcut keys

2. Customize through customizing a class

Custom commit rules

Detailed `questions` content