Improve documentatiion, mainly re. git.tagMatch

README.md

@@ -255,7 +255,7 @@ will run one after another. Some example release-it configuration:
 The variables can be found in the [default configuration](./config/release-it.json). Additionally, the following
 variables are exposed:
 
-```
+```text
 version
 latestVersion
 changelog

docs/ci.md

@@ -41,7 +41,7 @@ Replace `[user]` and `[project]` with the actual values.
 To run release-it from a GitHub Action, here's an example job (fragment) to configure a Git user (to push the release
 commit), and expose the `GITHUB_TOKEN` for the GitHub Release:
 
-```
+```yaml
 jobs:
   release:
     runs-on: ubuntu-latest
@@ -68,7 +68,7 @@ To publish a package to the (or any) npm registry from within a CI or CD environ
 `NPM_TOKEN` available in the `.npmrc` file. This file should look like this before release-it attempts to publish the
 package:
 
-```
+```text
 //registry.npmjs.org/:_authToken=$NPM_TOKEN
 ```
 
@@ -78,7 +78,7 @@ One way to achieve this is to set the `NPM_TOKEN` in the CI environment, and fro
 npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
 ```
 
-This will create/update the `.npmrc` file and add the token there. Ideally you should either `.gitignore` this file, 
+This will create/update the `.npmrc` file and add the token there. Ideally you should either `.gitignore` this file,
 otherwise you might end up committing it to your repo if you are using release-it's `git` options.
 
 Since release-it executes `npm whoami` as a [prerequisite check](./npm.md#prerequisite-checks), which does not seem to

docs/git.md

@@ -40,14 +40,18 @@ different git url.
 Use `git.tagName` to set a custom tag, not strictly equal to the (prefixed) version. When the latest tag has the `v`
 prefix, it will be used again. No need to configure `git.tagName: "v${version}"` in this case.
 
-Example: `git.tagName=${name}@${version}`
+Example: `--git.tagName=${name}@${version}`
 
 ## Tag Match
 
-Use `git.tagMatch` to override the normal matching behavior to find the latest tag. This can be useful when using a
-plugin to determine the next tag.
+Use `git.tagMatch` to override the normal matching behavior to find the latest tag. For instance, when doing a major
+release to find and set the latest major tag, and include all commits in the changelog since this matching tag.
 
-Example: `git.tagMatch='[0-9][0-9].[0-1][0-9].[0-9]*'`
+Example: `git.tagMatch: "[0-9]+\\.[0-9]+\\.[0-9]+"`
+
+This can be useful when using a plugin to determine the next tag:
+
+Example: `git.tagMatch: "[0-9][0-9].[0-1][0-9].[0-9]*"`
 
 ## Extra arguments
 
@@ -102,7 +106,7 @@ Use an array to allow releases from more branch names. Wildcards are also allowe
 
 The working directory should be clean (i.e. `git status` should say something like this:
 
-```
+```bash
 $ git status
 On branch master
 Your branch is up to date with 'origin/master'.

docs/plugins.md

@@ -314,7 +314,7 @@ Use template variables to render replacements. For instance, the command `git lo
 `git log v1.2.3...HEAD` before being executed. The replacements are all configuration options (with the default values
 in [config/release-it.json](../config/release-it.json)), plus the following additional variables:
 
-```
+```text
 version
 latestVersion
 latestTag

docs/pre-releases.md

@@ -43,6 +43,14 @@ release-it major
 
 <img src="./assets/release-it-prerelease.gif?raw=true" height="524">
 
+When all commits since the latest major tag should be added to the changelog, use `--git.tagMatch`:
+
+```bash
+release-it major --git.tagMatch='[0-9]+\\.[0-9]+\\.[0-9]+'
+```
+
+This will find the latest major matching tag, skipping the pre-release tags.
+
 Let's go back to when the latest release was `2.0.0-rc.0`. We added new features, which we don't want in the v2 release
 yet, but instead in a later v2.1. A new pre-release id can be made for the minor release after in `2.1.0-alpha.0`: