docs: capitalize commitizen for consistency

bearomorphism · bearomorphism · commit 247d2966c76e · 2025-05-30T20:15:31.000+08:00
diff --git a/docs/README.md b/docs/README.md
@@ -8,7 +8,7 @@
 [![Codecov](https://img.shields.io/codecov/c/github/commitizen-tools/commitizen.svg?style=flat-square)](https://codecov.io/gh/commitizen-tools/commitizen)
 [![pre-commit](https://img.shields.io/badge/pre--commit-enabled-brightgreen?style=flat-square&logo=pre-commit&logoColor=white)](https://github.com/pre-commit/pre-commit)
 
-![Using commitizen cli](images/demo.gif)
+![Using Commitizen cli](images/demo.gif)
 
 ---
 
diff --git a/docs/commands/bump.md b/docs/commands/bump.md
@@ -116,7 +116,7 @@ Below are some examples that illustrate the difference in behavior:
 
 ### `--check-consistency`
 
-Check whether the versions defined in `version_files` and the version in commitizen
+Check whether the versions defined in `version_files` and the version in Commitizen
 configuration are consistent before bumping version.
 
 ```bash
@@ -148,7 +148,7 @@ from setuptools import setup
 setup(..., version="1.0.5", ...)
 ```
 
-If `--check-consistency` is used, commitizen will check whether the current version in `pyproject.toml`
+If `--check-consistency` is used, Commitizen will check whether the current version in `pyproject.toml`
 exists in all version_files and find out it does not exist in `setup.py` and fails.
 However, it will still update `pyproject.toml` and `src/__version__.py`.
 
@@ -174,11 +174,11 @@ If `--local-version` is used, it will bump only the local version `0.1.0` and ke
 
 ### `--annotated-tag`
 
-If `--annotated-tag` is used, commitizen will create annotated tags. Also available via configuration, in `pyproject.toml` or `.cz.toml`.
+If `--annotated-tag` is used, Commitizen will create annotated tags. It is also available via configuration, in `pyproject.toml` or `.cz.toml`.
 
 ### `--annotated-tag-message`
 
-If `--annotated-tag-message` is used, commitizen will create annotated tags with the given message.
+If `--annotated-tag-message` is used, Commitizen will create annotated tags with the given message.
 
 ### `--changelog-to-stdout`
 
@@ -332,11 +332,11 @@ cz bump --allow-no-commit 2.0.0
 
 ## Avoid raising errors
 
-Some situations from commitizen raise an exit code different than 0.
-If the error code is different than 0, any CI or script running commitizen might be interrupted.
+Some situations from Commitizen raise an exit code different from 0.
+If the error code is different from 0, any CI or script running Commitizen might be interrupted.
 
 If you have a special use case, where you don't want to raise one of this error codes, you can
-tell commitizen to not raise them.
+tell Commitizen to not raise them.
 
 ### Recommended use case
 
@@ -355,7 +355,7 @@ cz -nr 21 bump
 
 ### Easy way
 
-Check which error code was raised by commitizen by running in the terminal
+Check which error code was raised by Commitizen by running in the terminal
 
 ```sh
 echo $?
@@ -367,13 +367,13 @@ The output should be an integer like this
 3
 ```
 
-And then you can tell commitizen to ignore it:
+And then you can tell Commitizen to ignore it:
 
 ```sh
 cz --no-raise 3
 ```
 
-You can tell commitizen to skip more than one if needed:
+You can tell Commitizen to skip more than one if needed:
 
 ```sh
 cz --no-raise 3,4,5
@@ -510,7 +510,7 @@ update_changelog_on_bump = true
 
 ### `annotated_tag`
 
-When set to `true` commitizen will create annotated tags.
+When set to `true`, Commitizen will create annotated tags.
 
 ```toml
 [tool.commitizen]
@@ -521,7 +521,7 @@ annotated_tag = true
 
 ### `gpg_sign`
 
-When set to `true` commitizen will create gpg signed tags.
+When set to `true`, Commitizen will create gpg signed tags.
 
 ```toml
 [tool.commitizen]
@@ -532,7 +532,7 @@ gpg_sign = true
 
 ### `major_version_zero`
 
-When set to `true` commitizen will keep the major version at zero.
+When set to `true`, Commitizen will keep the major version at zero.
 Useful during the initial development stage of your project.
 
 Defaults to: `false`
diff --git a/docs/commands/commit.md b/docs/commands/commit.md
@@ -1,4 +1,4 @@
-![Using commitizen cli](../images/demo.gif)
+![Using Commitizen cli](../images/demo.gif)
 
 ## About
 
@@ -20,14 +20,14 @@ case for this is to [automatically prepare a commit message](../tutorials/auto_p
 
 ### git options
 
-`git` command options that are not implemented by commitizen can be use via the `--` syntax for the `commit` command.
-The syntax separates commitizen arguments from `git commit` arguments by a double dash. This is the resulting syntax:
+`git` command options that are not implemented by Commitizen can be use via the `--` syntax for the `commit` command.
+The syntax separates Commitizen arguments from `git commit` arguments by a double dash. This is the resulting syntax:
 ```sh
 cz commit <commitizen-args> -- <git-cli-args>
 
 # e.g., cz commit --dry-run -- -a -S
 ```
-For example, using the `-S` option on `git commit` to sign a commit is now commitizen compatible: `cz c -- -S`
+For example, using the `-S` option on `git commit` to sign a commit is now Commitizen compatible: `cz c -- -S`
 
 !!! note
     Deprecation warning: A commit can be signed off using `cz commit --signoff` or the shortcut `cz commit -s`.
@@ -37,7 +37,7 @@ For example, using the `-S` option on `git commit` to sign a commit is now commi
 
 You can use `cz commit --retry` to reuse the last commit message when the previous commit attempt failed.
 To automatically retry when running `cz commit`, you can set the `retry_after_failure`
-configuration option to `true`. Running `cz commit --no-retry` makes commitizen ignore `retry_after_failure`, forcing
+configuration option to `true`. Running `cz commit --no-retry` makes Commitizen ignore `retry_after_failure`, forcing
 a new commit message to be prompted.
 
 ### Commit message length limit
diff --git a/docs/commands/init.md b/docs/commands/init.md
@@ -4,7 +4,7 @@
 
 ## Example
 
-To start using commitizen, the recommended approach is to run
+To start using Commitizen, the recommended approach is to run
 
 ```sh
 cz init
diff --git a/docs/commands/version.md b/docs/commands/version.md
@@ -1,4 +1,4 @@
-Get the version of the installed commitizen or the current project (default: installed commitizen)
+Get the version of the installed Commitizen or the current project (default: installed commitizen)
 
 ## Usage
 
diff --git a/docs/config.md b/docs/config.md
@@ -187,7 +187,7 @@ Type: `bool`
 
 Default: `false`
 
-If enabled, commitizen will show keyboard shortcuts when selecting from a list. Define a `key` for each of your choices to set the key. [Read more][shortcuts]
+If enabled, Commitizen will show keyboard shortcuts when selecting from a list. Define a `key` for each of your choices to set the key. [Read more][shortcuts]
 
 ### `major_version_zero`
 
@@ -341,14 +341,14 @@ commitizen:
 ## Version providers
 
 Commitizen can read and write version from different sources.
-By default, it uses the `commitizen` one which is using the `version` field from the commitizen settings.
+By default, it uses the `commitizen` one which is using the `version` field from the Commitizen settings.
 But you can use any `commitizen.provider` entrypoint as value for `version_provider`.
 
 Commitizen provides some version providers for some well known formats:
 
 | name         | description                                                                                                                                                                                                             |
 | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `commitizen` | Default version provider: Fetch and set version in commitizen config.                                                                                                                                                   |
+| `commitizen` | Default version provider: Fetch and set version in Commitizen config.                                                                                                                                                   |
 | `scm`        | Fetch the version from git and does not need to set it back                                                                                                                                                             |
 | `pep621`     | Get and set version from `pyproject.toml` `project.version` field                                                                                                                                                       |
 | `poetry`     | Get and set version from `pyproject.toml` `tool.poetry.version` field                                                                                                                                                   |
diff --git a/docs/contributing.md b/docs/contributing.md
@@ -61,7 +61,7 @@ If you're a first-time contributor, you can check the issues with the [good firs
     - Ensure test coverage doesn't drop (we use [CodeCov](https://app.codecov.io/gh/commitizen-tools/commitizen))
     - For documentation changes, run `poetry doc` to check for warnings/errors
 4. **Committing Changes**
-    - Use commitizen to make commits (we follow [conventional commits](https://www.conventionalcommits.org/))
+    - Use Commitizen to make commits (we follow [conventional commits](https://www.conventionalcommits.org/))
     - Example: `cz commit`
 5. **Documentation**
     - Update `docs/README.md` if needed
diff --git a/docs/customization.md b/docs/customization.md
@@ -1,12 +1,12 @@
-Customizing commitizen is not hard at all.
+Customizing Commitizen is not hard at all.
 We have two different ways to do so.
 
 ## 1. Customize in configuration file
 
 The basic steps are:
 
 1. Define your custom committing or bumping rules in the configuration file.
-2. Declare `name = "cz_customize"` in your configuration file, or add `-n cz_customize` when running commitizen.
+2. Declare `name = "cz_customize"` in your configuration file, or add `-n cz_customize` when running Commitizen.
 
 Example:
 
@@ -184,8 +184,8 @@ commitizen:
 
 #### Shortcut keys
 
-When the [`use_shortcuts`](config.md#settings) 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.
+When the [`use_shortcuts`](config.md#settings) 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
@@ -304,7 +304,7 @@ class StrangeCommitizen(BaseCommitizen):
     bump_map = {"break": "MAJOR", "new": "MINOR", "fix": "PATCH", "hotfix": "PATCH"}
 ```
 
-That's it, your commitizen now supports custom rules, and you can run.
+That's it, your Commitizen now supports custom rules, and you can run.
 
 ```bash
 cz -n cz_strange bump
@@ -451,7 +451,7 @@ Commitizen gives you the possibility to provide your own changelog template, by:
   - as `--template` parameter to both `bump` and `changelog` commands
 - either by providing a template with the same name as the default template
 
-By default, the template used is the `CHANGELOG.md.j2` file from the commitizen repository.
+By default, the template used is the `CHANGELOG.md.j2` file from the Commitizen repository.
 
 ### Providing a template with your customization class
 
diff --git a/docs/exit_codes.md b/docs/exit_codes.md
@@ -20,7 +20,7 @@ These exit codes can be found in `commitizen/exceptions.py::ExitCode`.
 | NoCommitBackupError         | 10        | Commit back up file cannot be found                                                                         |
 | NothingToCommitError        | 11        | Nothing in staging to be committed                                                                          |
 | CustomError                 | 12        | `CzException` raised                                                                                        |
-| NoCommandFoundError         | 13        | No command found when running commitizen cli (e.g., `cz --debug`)                                           |
+| NoCommandFoundError         | 13        | No command found when running Commitizen cli (e.g., `cz --debug`)                                           |
 | InvalidCommitMessageError   | 14        | The commit message does not pass `cz check`                                                                 |
 | MissingConfigError          | 15        | Configuration missed for `cz_customize`                                                                     |
 | NoRevisionError             | 16        | No revision found                                                                                           |
diff --git a/docs/external_links.md b/docs/external_links.md
@@ -1,4 +1,4 @@
-> If you have written over commitizen, make a PR and add the link here 💪
+> If you have written over Commitizen, make a PR and add the link here 💪
 
 ## Talks
 
diff --git a/docs/faq.md b/docs/faq.md
@@ -63,7 +63,7 @@ Where do they cross paths?
 
 If you are using conventional commits in your git history, then you could swap one with the other in theory.
 
-Regarding the name, [cz-js][cz-js] came first, they used the word commitizen first. When this project was created originally, the creator read "be a good commitizen", and thought it was just a cool word that made sense, and this would be a package that helps you be a good "commit citizen".
+Regarding the name, [cz-js][cz-js] came first, they used the word Commitizen first. When this project was created originally, the creator read "be a good commitizen", and thought it was just a cool word that made sense, and this would be a package that helps you be a good "commit citizen".
 
 [cz-js]: https://github.com/commitizen/cz-cli
 
@@ -80,7 +80,7 @@ This error was caused by a Python bug on Windows. It's been fixed by [this PR](h
 
 More discussion can be found in issue [#318](https://github.com/commitizen-tools/commitizen/issues/318).
 
-## Why does commitizen not support CalVer?
+## Why does Commitizen not support CalVer?
 
 `commitizen` could support CalVer alongside SemVer, but in practice implementing CalVer
 creates numerous edge cases that are difficult to maintain ([#385]) and more generally,
@@ -117,7 +117,7 @@ New bumped tags will be in the new format but old ones will still work for:
 
 
 So given if you change from `myproject-$version` to `${version}` and then `v${version}`,
-your commitizen configuration will look like this:
+your Commitizen configuration will look like this:
 
 ```toml
 tag_format = "v${version}"
diff --git a/docs/third-party-commitizen.md b/docs/third-party-commitizen.md
@@ -33,9 +33,9 @@ pip install conventional-JIRA
 
 ### [GitHub JIRA Conventional](https://pypi.org/project/cz-github-jira-conventional/)
 
-This plugin extends the commitizen tools by:
+This plugin extends the Commitizen tools by:
 
-- requiring a JIRA issue id in the commit message
+- requiring a JIRA issue ID in the commit message
 - creating links to GitHub commits in the CHANGELOG.md
 - creating links to JIRA issues in the CHANGELOG.md
 
diff --git a/docs/tutorials/auto_prepare_commit_message.md b/docs/tutorials/auto_prepare_commit_message.md
@@ -2,7 +2,7 @@
 
 ## About
 
-It can be desirable to use commitizen for all types of commits (i.e. regular, merge,
+It can be desirable to use Commitizen for all types of commits (i.e. regular, merge,
 squash) so that the complete git history adheres to the commit message convention
 without ever having to call `cz commit`.
 
@@ -18,10 +18,10 @@ To automatically perform arbitrary cleanup steps after a successful commit you c
 > This hook is invoked by git-commit. It takes no parameters, and is invoked after a
 > commit is made.
 
-A combination of these two hooks allows for enforcing the usage of commitizen so that
-whenever a commit is about to be created, commitizen is used for creating the commit
+A combination of these two hooks allows for enforcing the usage of Commitizen so that
+whenever a commit is about to be created, Commitizen is used for creating the commit
 message. Running `git commit` or `git commit -m "..."` for example, would trigger
-commitizen and use the generated commit message for the commit.
+Commitizen and use the generated commit message for the commit.
 
 ## Installation
 
diff --git a/docs/tutorials/github_actions.md b/docs/tutorials/github_actions.md
@@ -50,7 +50,7 @@ where to output the content of the changelog for the newly created version.
 
 And then add a step using a GitHub action to create the release: `softprops/action-gh-release`
 
-The commitizen action creates an env variable called `REVISION`, containing the
+Commitizen action creates an env variable called `REVISION`, containing the
 newly created version.
 
 ```yaml
@@ -119,7 +119,7 @@ jobs:
           ./scripts/publish
 ```
 
-Notice that we are using poetry, and we are calling a bash script in `./scripts/publish`. You should configure the action, and publish with your tools (twine, poetry, etc.). Check [commitizen example](https://github.com/commitizen-tools/commitizen/blob/master/scripts/publish)
+Notice that we are using poetry, and we are calling a bash script in `./scripts/publish`. You should configure the action, and publish with your tools (twine, poetry, etc.). Check [Commitizen example](https://github.com/commitizen-tools/commitizen/blob/master/scripts/publish)
 You can also use [pypa/gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) to publish your package.
 
 Push the changes and that's it.
diff --git a/docs/tutorials/monorepo_guidance.md b/docs/tutorials/monorepo_guidance.md
@@ -1,4 +1,4 @@
-# Configuring commitizen in a monorepo
+# Configuring Commitizen in a monorepo
 
 This tutorial assumes the monorepo layout is designed with multiple components that can be released independently of each
 other, it also assumes that conventional commits with scopes are in use. Some suggested layouts:
diff --git a/docs/tutorials/writing_commits.md b/docs/tutorials/writing_commits.md
@@ -1,6 +1,6 @@
 For this project to work well in your pipeline, a commit convention must be followed.
 
-By default, commitizen uses the known [conventional commits][conventional_commits], but
+By default, Commitizen uses the known [conventional commits][conventional_commits], but
 you can create your own following the documentation information over at
 [customization][customization].
 

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-Get the version of the installed commitizen or the current project (default: installed commitizen)`
	`1`	`+Get the version of the installed Commitizen or the current project (default: installed commitizen)`
`2`	`2`
`3`	`3`	`## Usage`
`4`	`4`
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-> If you have written over commitizen, make a PR and add the link here 💪`
	`1`	`+> If you have written over Commitizen, make a PR and add the link here 💪`
`2`	`2`
`3`	`3`	`## Talks`
`4`	`4`