docs(config): split the configuration documentation into pages

Author: bearomorphism

docs/commands/bump.md

@@ -2,44 +2,37 @@
 
 This command will generate a changelog following the committing rules established.
 
-To create the changelog automatically on bump, add the setting [update_changelog_on_bump](./bump.md#update_changelog_on_bump)
+!!! tip
+    To create the changelog automatically on bump, add the setting [update_changelog_on_bump](../config/bump.md#update_changelog_on_bump)
 
-```toml
-[tool.commitizen]
-update_changelog_on_bump = true
-```
+    ```toml
+    [tool.commitizen]
+    update_changelog_on_bump = true
+    ```
 
 ## Usage
 
 ![cz changelog --help](../images/cli_help/cz_changelog___help.svg)
 
-### Examples
-
-#### Generate full changelog
+## Examples
 
 ```bash
+# Generate full changelog
 cz changelog
-```
 
-```bash
+# or use the alias
 cz ch
-```
 
-#### Get the changelog for the given version
-
-```bash
+# Get the changelog for the given version
 cz changelog 0.3.0 --dry-run
-```
-
-#### Get the changelog for the given version range
 
-```bash
+# Get the changelog for the given version range
 cz changelog 0.3.0..0.4.0 --dry-run
 ```
 
 ## Constrains
 
-changelog generation is constrained only to **markdown** files.
+Changelog generation is constrained only to **markdown** files.
 
 ## Description
 
@@ -72,51 +65,29 @@ and the following variables are expected:
 
 - **required**: is the only one required to be parsed by the regex
 
-## Configuration
-
-### `unreleased_version`
-
-There is usually a chicken and egg situation when automatically
-bumping the version and creating the changelog.
-If you bump the version first, you have no changelog, you have to
-create it later, and it won't be included in
-the release of the created version.
-
-If you create the changelog before bumping the version, then you
-usually don't have the latest tag, and the _Unreleased_ title appears.
-
-By introducing `unreleased_version` you can prevent this situation.
-
-Before bumping you can run:
-
-```bash
-cz changelog --unreleased-version="v1.0.0"
-```
-
-Remember to use the tag instead of the raw version number
+## Command line options
 
-For example if the format of your tag includes a `v` (`v1.0.0`), then you should use that,
-if your tag is the same as the raw version, then ignore this.
+### `--extras`
 
-Alternatively you can directly bump the version and create the changelog by doing
+Provides your own changelog extra variables by using the `extras` settings or the `--extra/-e` parameter.
 
 ```bash
-cz bump --changelog
+cz changelog --extra key=value -e short="quoted value"
 ```
 
-### `file-name`
+### `--file-name`
 
-This value can be updated in the `toml` file with the key `changelog_file` under `tools.commitizen`
+This value can be updated in the configuration file with the key `changelog_file` under `tools.commitizen`
 
 Specify the name of the output file, remember that changelog only works with Markdown.
 
 ```bash
 cz changelog --file-name="CHANGES.md"
 ```
 
-### `incremental`
+### `--incremental`
 
-This flag can be set in the `toml` file with the key `changelog_incremental` under `tools.commitizen`
+This flag can be set in the configuration file with the key `changelog_incremental` under `tools.commitizen`
 
 Benefits:
 
@@ -134,9 +105,9 @@ cz changelog --incremental
 changelog_incremental = true
 ```
 
-### `start-rev`
+### `--start-rev`
 
-This value can be set in the `toml` file with the key `changelog_start_rev` under `tools.commitizen`
+This value can be set in the configuration file with the key `changelog_start_rev` under `tools.commitizen`
 
 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.
 
@@ -150,9 +121,9 @@ cz changelog --start-rev="v0.2.0"
 changelog_start_rev = "v0.2.0"
 ```
 
-### merge-prerelease
+### `--merge-prerelease`
 
-This flag can be set in the `toml` file with the key `changelog_merge_prerelease` under `tools.commitizen`
+This flag can be set in the configuration file with the key `changelog_merge_prerelease` under `tools.commitizen`
 
 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.
 
@@ -166,20 +137,39 @@ cz changelog --merge-prerelease
 changelog_merge_prerelease = true
 ```
 
-### `template`
+### `--template`
 
 Provides your own changelog jinja template by using the `template` settings or the `--template` parameter.
-See [the template customization section](../customization.md#customizing-the-changelog-template)
 
-### `extras`
+### `--unreleased-version`
 
-Provides your own changelog extra variables by using the `extras` settings or the `--extra/-e` parameter.
+There is usually a chicken and egg situation when automatically
+bumping the version and creating the changelog.
+If you bump the version first, you have no changelog, you have to
+create it later, and it won't be included in
+the release of the created version.
+
+If you create the changelog before bumping the version, then you
+usually don't have the latest tag, and the _Unreleased_ title appears.
+
+By introducing `--unreleased-version` you can prevent this situation.
+
+Before bumping you can run:
 
 ```bash
-cz changelog --extra key=value -e short="quoted value"
+cz changelog --unreleased-version="v1.0.0"
 ```
 
-See [the template customization section](../customization.md#customizing-the-changelog-template)
+Remember to use the tag instead of the raw version number
+
+For example if the format of your tag includes a `v` (`v1.0.0`), then you should use that,
+if your tag is the same as the raw version, then ignore this.
+
+Alternatively you can directly bump the version and create the changelog by doing
+
+```bash
+cz bump --changelog
+```
 
 ## Hooks
 
@@ -192,4 +182,4 @@ Read more about hooks in the [customization page][customization]
 
 [keepachangelog]: https://keepachangelog.com/
 [semver]: https://semver.org/
-[customization]: ../customization.md
+[customization]: ../customization/config_file.md

docs/commands/changelog.md

@@ -11,7 +11,7 @@ The `commit` command provides an interactive way to create structured commits. U
 - `cz commit`
 - `cz c` (shortcut)
 
-By default, Commitizen uses conventional commits, but you can customize the commit rules to match your project's needs. See the [customization guide](../customization.md) for details.
+By default, Commitizen uses conventional commits, but you can customize the commit rules to match your project's needs. See the [customization guide](../customization/config_file.md) for details.
 
 ## Basic Usage
 

docs/commands/commit.md

@@ -20,10 +20,7 @@ When you run `cz init`, Commitizen will guide you through an interactive setup p
 
 The initialization process will create a configuration file in your project root.
 
-Choose the configuration file format based on your project type:
-
-- Use `pyproject.toml` for Python projects
-- Use `.cz.toml`, `.cz.yaml`, `.cz.json`, etc. for other projects.
+See [Configuration File][configuration_file] for more details.
 
 ## Configuration Options
 
@@ -48,6 +45,8 @@ During the initialization process, you'll be prompted to configure the following
 7. **Alpha Versioning**: Option to keep major version at 0 for alpha/beta software
 8. **Pre-commit Hooks**: Set up Git pre-commit hooks for automated commit message validation
 
+See [Configuration Options][configuration_options] for more details.
+
 ## Example
 
 ```sh
@@ -61,6 +60,9 @@ cz init
 
 After initialization, you can:
 
-1. Start using `cz commit` to create conventional commits
-2. Use `cz bump` to manage versioning
-3. Configure additional settings in your project's configuration file
+1. Start using [`cz commit`](./commit.md) to create conventional commits
+2. Use [`cz bump`](./bump.md) to manage versioning
+3. Configure additional settings in your project's [configuration_file][configuration_file]
+
+[configuration_file]: ../config/configuration_file.md
+[configuration_options]: ../config/option.md