Fix Markdown issues pointed out by markdown-lint

BREAKING_CHANGES.md

@@ -1,9 +1,9 @@
 ## v5.0.0
 
-- Version numbers in branches other than `release` branches are no longer
-  considered as a version source by default. Implemented in [#1541][pr-1541].
-- [#1581][pr-1581] folds `GitTools.Core` back into GitVersion to make
-  maintaining GitVersion easier.
+*   Version numbers in branches other than `release` branches are no longer
+    considered as a version source by default. Implemented in [#1541][pr-1541].
+*   [#1581][pr-1581] folds `GitTools.Core` back into GitVersion to make
+    maintaining GitVersion easier.
 
 ## v4.0.0
 
@@ -12,35 +12,35 @@
 When using GitFlow, a few things have changed. Hopefully the new settings just
 work for you
 
-- `develop` has pre-release tag of `alpha` now, not unstable.
-- `develop` will bump as soon as a `release` branch is created.
-- Look at the [GitFlow examples][gitflow] for details of how it works now.
+*   `develop` has pre-release tag of `alpha` now, not unstable.
+*   `develop` will bump as soon as a `release` branch is created.
+*   Look at the [GitFlow examples][gitflow] for details of how it works now.
 
 ### Configuration Changes
 
-- `GitVersionConfig.yaml` is deprecated in favor of `GitVersion.yml`.
-- Regular expressions are no longer used as keys in branch config
-    - We have named branches, and introduced a `regex` config which you can
-      override.
-    - The default keys are: `master`, `develop`, `feature`, `release`, `pull-request`,
-      `hotfix` and `support`
-    - Just run `GitVersion.exe` in your project directory and it will tell you
-      what to change your config keys to
-    - For example, `dev(elop)?(ment)?$` is now just `develop`, we suggest not
-      overring regular expressions unless you really want to use a different convention.
-- `source-branches` added as a configuration option for branches, it helps
-  GitVersion pick the correct source branch
+*   `GitVersionConfig.yaml` is deprecated in favor of `GitVersion.yml`.
+*   Regular expressions are no longer used as keys in branch config
+    *   We have named branches, and introduced a `regex` config which you can
+        override.
+    *   The default keys are: `master`, `develop`, `feature`, `release`, `pull-request`,
+        `hotfix` and `support`
+    *   Just run `GitVersion.exe` in your project directory and it will tell you
+        what to change your config keys to
+    *   For example, `dev(elop)?(ment)?$` is now just `develop`, we suggest not
+        overring regular expressions unless you really want to use a different convention.
+*   `source-branches` added as a configuration option for branches, it helps
+    GitVersion pick the correct source branch
 
 ## v3.0.0
 
-- NextVersion.txt has been deprecated, only `GitVersionConfig.yaml` is supported
-- `AssemblyFileSemVer` variable removed, `AssemblyVersioningScheme` configuration
-  value makes this variable obsolete
-- Variables `ClassicVersion` and `ClassicVersionWithTag` removed
-- MSBuild task arguments (`AssemblyVersioningScheme`, `DevelopBranchTag`,
-  `ReleaseBranchTag`, `TagPrefix`, `NextVersion`) have been removed, use
-  `GitVersionConfig.yaml` instead
-- GitVersionTask's `ReleaseDateAttribute` no longer exists
+*   NextVersion.txt has been deprecated, only `GitVersionConfig.yaml` is supported
+*   `AssemblyFileSemVer` variable removed, `AssemblyVersioningScheme` configuration
+    value makes this variable obsolete
+*   Variables `ClassicVersion` and `ClassicVersionWithTag` removed
+*   MSBuild task arguments (`AssemblyVersioningScheme`, `DevelopBranchTag`,
+    `ReleaseBranchTag`, `TagPrefix`, `NextVersion`) have been removed, use
+    `GitVersionConfig.yaml` instead
+*   GitVersionTask's `ReleaseDateAttribute` no longer exists
 
 [gitflow]: https://gitversion.net/docs/learn/branching-strategies/gitflow-examples_complete
 [pr-1541]: https://github.com/GitTools/GitVersion/pull/1541

CONTRIBUTING.md

@@ -2,10 +2,10 @@
 
 We love contributions to get started contributing you might need:
 
-- [Get started with git](http://rogerdudler.github.io/git-guide)
-- [How to create a pull request](https://help.github.com/articles/using-pull-requests)
-- [An issue to work on](https://github.com/GitTools/GitVersion/labels/up-for-grabs) - We are on [Up for grabs](http://up-for-grabs.net/), our up for grabs issues are tagged `up-for-grabs`
-- An understanding of our [architecture](http://gitversion.net/docs/learn/how-it-works#architecture) and how [we write tests](#writing-tests)
+*   [Get started with git](http://rogerdudler.github.io/git-guide)
+*   [How to create a pull request](https://help.github.com/articles/using-pull-requests)
+*   [An issue to work on](https://github.com/GitTools/GitVersion/labels/up-for-grabs) - We are on [Up for grabs](http://up-for-grabs.net/), our up for grabs issues are tagged `up-for-grabs`
+*   An understanding of our [architecture](http://gitversion.net/docs/learn/how-it-works#architecture) and how [we write tests](#writing-tests)
 
 Once you know how to create a pull request and have an issue to work on, just post a comment saying you will work on it.
 If you end up not being able to complete the task, please post another comment so others can pick it up.
@@ -14,12 +14,12 @@ Issues are also welcome, [failing tests](#writing-tests) are even more welcome.
 
 ## Contribution Guidelines
 
-- Try to use feature branches rather than developing on main.
-- Please include tests covering the change.
-- The documentation is stored in the repository under the [`docs`](docs) folder.
-   Have a look at the [documentation readme file](docs/readme.md) for guidance
-   on how to improve the documentation and please include documentation updates
-   with your PR.
+*   Try to use feature branches rather than developing on main.
+*   Please include tests covering the change.
+*   The documentation is stored in the repository under the [`docs`](docs) folder.
+    Have a look at the [documentation readme file](docs/readme.md) for guidance
+    on how to improve the documentation and please include documentation updates
+    with your PR.
 
 ## How it works
 
@@ -43,13 +43,13 @@ We are currently using NUnit, so just create a descriptive test method and attri
 
 We have a few fixtures for different scenarios.
 
-- `EmptyRepositoryFixture` - Gives you an empty git repo to start with
-- `RemoteRepositoryFixture` - A local repo tracking a test remote repository. The remote repo is available through the `Repository` property, the local is accessible via `LocalRepository`
-- `BaseGitFlowRepositoryFixture` - A repo setup for GitFlow (has a develop branch checked out ready to go)
+*   `EmptyRepositoryFixture` - Gives you an empty git repo to start with
+*   `RemoteRepositoryFixture` - A local repo tracking a test remote repository. The remote repo is available through the `Repository` property, the local is accessible via `LocalRepository`
+*   `BaseGitFlowRepositoryFixture` - A repo setup for GitFlow (has a develop branch checked out ready to go)
 
 You can use a fixture by just `using` it. Like this
 
-``` csharp
+```csharp
 using (var fixture = new EmptyRepositoryFixture(new Config()))
 {
 }
@@ -65,7 +65,7 @@ We have a number of extension method off `IRepository` to make it easy to write
 
 An example test looks like this:
 
-``` csharp
+```csharp
 fixture.Repository.MakeATaggedCommit("1.0.0");
 fixture.Repository.CreateBranch("feature-test");
 fixture.Repository.Checkout("feature-test");
@@ -85,22 +85,22 @@ Even better include the fix, but a failing test is a great start
 
 We use Cake for our build and deployment process. The way the build / release process is setup is:
 
-1) We build releasable artifacts on AppVeyor
-1) Login to AppVeyor
-1) Deploy the latest main build
-![docs/input/docs/img/release-1-deploy.png](docs/input/docs/img/release-1-deploy.png)
-1) Choose GitVersion release, when you press deploy it will create a *non-released* GitHub release, this *will not* create a Git tag. This step is so we can validate the release and release notes before pushing the button.
-![docs/input/docs/img/release-2-deploy.png](docs/input/docs/img/release-2-deploy.png)
-1) All the artifacts should upload nicely
-![docs/input/docs/img/release-3-deploy.png](docs/input/docs/img/release-3-deploy.png)
-1) Head over to GitHub releases, you should have a draft release, download a copy of the release notes
-![docs/input/docs/img/release-4-deploy.png](docs/input/docs/img/release-4-deploy.png)
-1) Edit the release and do the following:
-    1. Remove the build metadata from the tag and title (the + and everything after it)
-    2. Paste the downloaded release notes in, you can clean them up if you want otherwise there may be closed issues which were questions etc.
-    3. Tick the pre-release box if it's pre-release
-    4. Press Publish
-1) Publishing tags (a git tag) the release commit, this will trigger another appveyor build which only builds tags, this build uses deploy.cake. It downloads the artifacts from that GitHub release, then performs the release
+1.  We build releasable artifacts on AppVeyor
+2.  Login to AppVeyor
+3.  Deploy the latest main build
+    ![docs/input/docs/img/release-1-deploy.png](docs/input/docs/img/release-1-deploy.png)
+4.  Choose GitVersion release, when you press deploy it will create a _non-released_ GitHub release, this _will not_ create a Git tag. This step is so we can validate the release and release notes before pushing the button.
+    ![docs/input/docs/img/release-2-deploy.png](docs/input/docs/img/release-2-deploy.png)
+5.  All the artifacts should upload nicely
+    ![docs/input/docs/img/release-3-deploy.png](docs/input/docs/img/release-3-deploy.png)
+6.  Head over to GitHub releases, you should have a draft release, download a copy of the release notes
+    ![docs/input/docs/img/release-4-deploy.png](docs/input/docs/img/release-4-deploy.png)
+7.  Edit the release and do the following:
+    1.  Remove the build metadata from the tag and title (the + and everything after it)
+    2.  Paste the downloaded release notes in, you can clean them up if you want otherwise there may be closed issues which were questions etc.
+    3.  Tick the pre-release box if it's pre-release
+    4.  Press Publish
+8.  Publishing tags (a git tag) the release commit, this will trigger another appveyor build which only builds tags, this build uses deploy.cake. It downloads the artifacts from that GitHub release, then performs the release
 
 ## Docker
 
@@ -109,17 +109,19 @@ It is a manual release step after the release now, first download the appropriat
 ```bash
 docker build . --build-arg GitVersionZip=GitVersion_<VERSION>.zip --tag gittools/gitversion
 ```
+
 ## Code Style
 
 In order to apply the code style defined by by the `.editorconfig` file you can use [`dotnet-format`](https://github.com/dotnet/format).
 
-1. Install [`dotnet-format`](https://github.com/dotnet/format) as a global tool:
+1.  Install [`dotnet-format`](https://github.com/dotnet/format) as a global tool:
 
 ```shell
 dotnet tool install -g dotnet-format
 ```
 
-2. Change to the root folder of the GitVersion repository and use the following command to apply the code style:
+2.  Change to the root folder of the GitVersion repository and use the following command to apply the code style:
+
 ```shell
 dotnet format ./ --folder --exclude **/AddFormats/ --fix-codestyle
-```
+```

README.md

@@ -14,7 +14,7 @@ works out the [Semantic Version][semver] of the commit being built.
 | **GitVersion.Portable**    |                     [![Chocolatey][choco-badge]][choco]            |
 | **GitVersion.Tool**        |                           [![NuGet][gvgt-badge]][gvgt]             |
 | **GitVersion.CommandLine** |                           [![NuGet][gvcl-badge]][gvcl]             |
-| **GitVersion.MsBuild**     |                            [![NuGet][gvt-badge]][gvt]              | Known as *[GitVersionTask][GitVersionTask]*  before v5.6.0 |
+| **GitVersion.MsBuild**     |                            [![NuGet][gvt-badge]][gvt]              | Known as [GitVersionTask] before v5.6.0 |
 | **Homebrew**               |                        [![homebrew][brew-badge]][brew]             |
 | **Azure Pipeline Task**    | [![Azure Pipeline Task][az-pipeline-task-badge]][az-pipeline-task] |
 | **Github Action**          |             [![Github Action][gh-actions-badge]][gh-actions]       |
@@ -26,22 +26,22 @@ GitVersion works on Windows, Linux, and Mac.
 
 ## Quick Links
 
-- [Documentation][docs]
-- [Contributing][contribute]
-- [Why GitVersion][why]
-- [Usage][usage]
-- [How it works][how]
-- [FAQ][faq]
-- [Who is using GitVersion][who]
+*   [Documentation][docs]
+*   [Contributing][contribute]
+*   [Why GitVersion][why]
+*   [Usage][usage]
+*   [How it works][how]
+*   [FAQ][faq]
+*   [Who is using GitVersion][who]
 
 ## GitVersion in action!
 
 ![README][gv-in-action]
 
 You are seeing:
 
-- Pull requests being built as pre-release builds
-- A branch called `release-1.0.0` producing beta v1 packages
+*   Pull requests being built as pre-release builds
+*   A branch called `release-1.0.0` producing beta v1 packages
 
 ## Icon
 

docs/input/docs/learn/branching-strategies/contribute-examples.md

@@ -8,10 +8,10 @@ The examples are generated by GitVersion tests, there are a number of services
 which will then turn the sequence diagram text into an image to use in the docs.
 Here are some links which could be useful
 
-- [PlantUML Sequence Diagrams](http://www.plantuml.com/sequence.html)
-- [CodeUML Online editor](http://www.codeuml.com/)
-- [PlantText Online editor](http://www.planttext.com/planttext)
-- [PlantUML gist renderer](http://uml.mvnsearch.org)
+*   [PlantUML Sequence Diagrams](http://www.plantuml.com/sequence.html)
+*   [CodeUML Online editor](http://www.codeuml.com/)
+*   [PlantText Online editor](http://www.planttext.com/planttext)
+*   [PlantUML gist renderer](http://uml.mvnsearch.org)
 
 The tests are quite simple. Using the methods on the `fixture` itself will
 record that action in the sequence diagram. If you do not want the action

docs/input/docs/learn/branching-strategies/gitflow/examples.md

@@ -3,7 +3,7 @@ Order: 40
 Title: GitFlow Examples
 ---
 
-These examples are using the *default* configuration with GitVersion. Which is
+These examples are using the _default_ configuration with GitVersion. Which is
 [continuous deployment](/docs/reference/modes/continuous-deployment) mode for
 `develop` and [continuous delivery](/docs/reference/modes/continuous-delivery) mode
 for all other branches.
@@ -17,11 +17,11 @@ then tagged. Read more about this at [version increments](/docs/reference/versio
 Feature branches will take the feature branch name and use that as the
 pre-release tag.
 
-![GitFlow](/docs/img/05119d0cd4ecaaefff94_feature-branch.png)
+![GitFlow](/docs/img/05119d0cd4ecaaefff94\_feature-branch.png)
 
 Notice after the feature branch is merged, the version on `develop` is
-`1.3.0-alpha.3`. This is due to `develop` running in *continuous deployment*
-mode. If you configured `develop` to use *continuous delivery* the version would
+`1.3.0-alpha.3`. This is due to `develop` running in _continuous deployment_
+mode. If you configured `develop` to use _continuous delivery_ the version would
 still be `1.3.0-alpha.1` and you would have to use release tags to increment the
 `alpha.1`.
 
@@ -39,25 +39,25 @@ pull request branch name which is created when you submit a pull request
 
 ## Hotfix Branches
 
-Hotfix branches are used when you need to do a *patch* release in GitFlow and
+Hotfix branches are used when you need to do a _patch_ release in GitFlow and
 are always created off `main`
 
-![GitFlow](/docs/img/f26ae57adbd9b74f74c4_hotfix.png)
+![GitFlow](/docs/img/f26ae57adbd9b74f74c4\_hotfix.png)
 
 ## Minor Release Branches
 
 Release branches are used for both major and minor releases for stabilisation
 before a release. Release branches are taken off `develop` then merged to both
 `develop` and `main`. Finally `main` is tagged with the released version.
 
-![GitFlow](/docs/img/6d33d35a70a777608fa1_minor-release.png)
+![GitFlow](/docs/img/6d33d35a70a777608fa1\_minor-release.png)
 
 ## Major Release Branches
 
 Major releases are just like minor releases, the difference is you bump the
 major in the release branch name.
 
-![GitFlow](/docs/img/39f9d8b8b007c82f1f80_major-release.png)
+![GitFlow](/docs/img/39f9d8b8b007c82f1f80\_major-release.png)
 
 ## Support Branches
 
@@ -73,12 +73,12 @@ support minors use `support/<major>.<minor>.x` or `support/<major>.<minor>.0`.
 Depending on what you name your support branch, you may or may not need a hotfix
 branch. Naming it `support/1.x` will automatically bump the patch, if you name
 it `support/1.3.0` then the version in branch name rule will kick in and the
-patch *will not* automatically bump, meaning you have to use hotfix branches.
-![GitFlow](/docs/img/b035b8ca99bd34239518_support-hotfix.png)
+patch _will not_ automatically bump, meaning you have to use hotfix branches.
+![GitFlow](/docs/img/b035b8ca99bd34239518\_support-hotfix.png)
 
 ### Minor Release
 
-![GitFlow](/docs/img/2167fb1c4a5cf84edfd8_support-minor.png)
+![GitFlow](/docs/img/2167fb1c4a5cf84edfd8\_support-minor.png)
 
 ## To Contribute
 
@@ -91,4 +91,4 @@ See [contributing examples](/docs/learn/branching-strategies/contribute-examples
 ### Source
 
 See `DocumentationSamples.GitFlowExample`. To update, modify then run test.
-Update [https://gist.github.com/JakeGinnivan/cf053d7f5d336ae9f7bb](https://gist.github.com/JakeGinnivan/cf053d7f5d336ae9f7bb)
+Update <https://gist.github.com/JakeGinnivan/cf053d7f5d336ae9f7bb>