fix markdown files

.markdownlint.json

@@ -1,3 +1,4 @@
 {
-    "MD026": false
+    "MD026": false,
+    "MD041": false
 }

CONTRIBUTING.md

@@ -2,10 +2,10 @@
 
 We love contributions to get started contributing you might need:
 
-*   [Get started with git](https://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](https://up-for-grabs.net/), our up for grabs issues are tagged `up-for-grabs`
-*   An understanding of our [architecture](https://gitversion.net/docs/learn/how-it-works#architecture) and how [we write tests](#writing-tests)
+* [Get started with git](https://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](https://up-for-grabs.net/), our up for grabs issues are tagged `up-for-grabs`
+* An understanding of our [architecture](https://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,9 +14,9 @@ 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.
+* 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.
@@ -50,6 +50,7 @@ var configurationBuilder = GitFlowConfigurationBuilder.New;
 We can then customize the configuration by chaining methods of the builder. At the end we build the configuration.
 
 For example:
+
 ```csharp
 var configuration = configurationBuilder
     .WithDeploymentMode(DeploymentMode.ContinuousDeployment)
@@ -61,9 +62,9 @@ var configuration = configurationBuilder
 
 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
 
@@ -97,18 +98,18 @@ 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 release process is setup is:
 
-1.  We build releasable artifacts with GitHub Actions
-2.  We create a milestone for the release if it's not already created. Our milestones are named using the semver.
+1. We build releasable artifacts with GitHub Actions
+2. We create a milestone for the release if it's not already created. Our milestones are named using the semver.
     For example `5.12.0` or `6.0.0-beta.2`
-3.  We move all the closed issues and closed pull requests that are going to be included in the release to the milestone.
-4.  We check that all the issues and pull requests that are going to be included in the release have a label assigned,
+3. We move all the closed issues and closed pull requests that are going to be included in the release to the milestone.
+4. We check that all the issues and pull requests that are going to be included in the release have a label assigned,
     otherwise it will fail the release.
-5.  We create a release in the GitHub UI, and create a tag and name it using the milestone name. For example `5.12.0` or `6.0.0-beta.2`
-6.  We specify if the release is a pre-release or latest release in the GitHub UI.
-7.  We publish the release.
-8.  The GitHub Actions will create a GitHub release and publish the artifacts to NuGet, Chocolatey, Docker, Homebrew
+5. We create a release in the GitHub UI, and create a tag and name it using the milestone name. For example `5.12.0` or `6.0.0-beta.2`
+6. We specify if the release is a pre-release or latest release in the GitHub UI.
+7. We publish the release.
+8. The GitHub Actions will create a GitHub release and publish the artifacts to NuGet, Chocolatey, Docker, Homebrew
     and other distribution channels.
-9.  The issues and pull requests will get updated with message specifying in which release it was included.
+9. The issues and pull requests will get updated with message specifying in which release it was included.
 
 ## Code Style
 

README.md

@@ -1,4 +1,4 @@
-![GitVersion – From git log to SemVer in no time][banner]
+# ![GitVersion – From git log to SemVer in no time][banner]
 
 Versioning when using Git, solved. GitVersion looks at your git history and
 works out the [Semantic Version][semver] of the commit being built.
@@ -27,22 +27,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
 

SECURITY.md

@@ -17,13 +17,13 @@ You should receive a response within 24 hours. If for some reason you do not, pl
 
 Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
 
-*   Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
-*   Full paths of source file(s) related to the manifestation of the issue
-*   The location of the affected source code (tag/branch/commit or direct URL)
-*   Any special configuration required to reproduce the issue
-*   Step-by-step instructions to reproduce the issue
-*   Proof-of-concept or exploit code (if possible)
-*   Impact of the issue, including how an attacker might exploit the issue
+* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
+* Full paths of source file(s) related to the manifestation of the issue
+* The location of the affected source code (tag/branch/commit or direct URL)
+* Any special configuration required to reproduce the issue
+* Step-by-step instructions to reproduce the issue
+* Proof-of-concept or exploit code (if possible)
+* Impact of the issue, including how an attacker might exploit the issue
 
 This information will help us triage your report more quickly.
 

build/nuspec/README.md

@@ -16,22 +16,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
 
@@ -46,8 +46,6 @@ from The Noun Project.
 [gvt]:                             https://www.nuget.org/packages/GitVersion.MsBuild
 [gvt-badge]:                       https://img.shields.io/nuget/v/GitVersion.MsBuild.svg?logo=nuget
 [gitversiontask]:                  https://www.nuget.org/packages/GitVersionTask/
-[gvcl]:                            https://www.nuget.org/packages/GitVersion.CommandLine
-[gvcl-badge]:                      https://img.shields.io/nuget/v/GitVersion.CommandLine.svg?logo=nuget
 [gvgt]:                            https://www.nuget.org/packages/GitVersion.Tool
 [gvgt-badge]:                      https://img.shields.io/nuget/v/GitVersion.Tool.svg?logo=nuget
 [contribute]:                      https://github.com/GitTools/GitVersion/blob/main/CONTRIBUTING.md

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

@@ -9,8 +9,8 @@ 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](https://www.plantuml.com/sequence.html)
-*   [PlantText Online editor](https://www.planttext.com)
+* [PlantUML Sequence Diagrams](https://www.plantuml.com/sequence.html)
+* [PlantText Online editor](https://www.planttext.com)
 
 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/index.md

@@ -10,29 +10,29 @@ SemVer compatible versions from this structure.
 
 ## Assumptions:
 
-*   Using [GitFlow branching model](https://nvie.com/git-model/) which always has a
+* Using [GitFlow branching model](https://nvie.com/git-model/) which always has a
     main and a develop branch
-*   Following [Semantic Versioning](https://semver.org/)
-*   Planned releases (bumps in major or minor) are done on release branches
+* Following [Semantic Versioning](https://semver.org/)
+* Planned releases (bumps in major or minor) are done on release branches
     prefixed with release-. Eg: release-4.1 (or release-4.1.0)
-*   Hotfixes are prefixed with hotfix- Eg. hotfix-4.0.4
-*   The original [GitFlow model](https://nvie.com/posts/a-successful-git-branching-model/)
+* Hotfixes are prefixed with hotfix- Eg. hotfix-4.0.4
+* The original [GitFlow model](https://nvie.com/posts/a-successful-git-branching-model/)
     specifies branches with a "-" separator while the [git flow extensions](https://github.com/CJ-Systems/gitflow-cjs)
     default to a "/" separator.  Either work with GitVersion.
-*   Tags are used on the main branch and reflects the SemVer of each stable
+* Tags are used on the main branch and reflects the SemVer of each stable
     release eg 3.3.8 , 4.0.0, etc
-*   Tags can also be used to override versions while we transition repositories
+* Tags can also be used to override versions while we transition repositories
     over to GitVersion
-*   Using a build server with multi-branch building enabled eg TeamCity 8
+* Using a build server with multi-branch building enabled eg TeamCity 8
 
 ## How Branches are handled
 
 The descriptions of how commits and branches are versioned can be considered a
 type of pseudopod. With that in mind there are a few common "variables" that we
 will refer to:
 
-*   `targetBranch` => the branch we are targeting
-*   `targetCommit` => the commit we are targeting on `targetbranch`
+* `targetBranch` => the branch we are targeting
+* `targetCommit` => the commit we are targeting on `targetbranch`
 
 ### Main branch
 
@@ -44,15 +44,15 @@ If we try to build from a commit that is no merge and no tag then assume `0.1.0`
 
 `mergeVersion` => the SemVer extracted from `targetCommit.Message`
 
-*   major: `mergeVersion.Major`
-*   minor: `mergeVersion.Minor`
-*   patch: `mergeVersion.Patch`
-*   pre-release: 0 (perhaps count ahead commits later)
-*   stability: final
+* major: `mergeVersion.Major`
+* minor: `mergeVersion.Minor`
+* patch: `mergeVersion.Patch`
+* pre-release: 0 (perhaps count ahead commits later)
+* stability: final
 
 Optional Tags (only when transitioning existing repository):
 
-*   TagOnHeadCommit.Name={semver} => overrides the version to be {semver}
+* TagOnHeadCommit.Name={semver} => overrides the version to be {semver}
 
 Long version:
 
@@ -68,10 +68,10 @@ Long version:
 `main` that is older than the `targetCommitDate`
 `mainMergeVersion` => the SemVer extracted from `mainVersionCommit.Message`
 
-*   major: `mainMergeVersion.Major`
-*   minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
-*   patch: 0
-*   pre-release: `alpha.{n}` where n = how many commits `develop` is in front of
+* major: `mainMergeVersion.Major`
+* minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
+* patch: 0
+* pre-release: `alpha.{n}` where n = how many commits `develop` is in front of
     `mainVersionCommit.Date` ('0' padded to 4 characters)
 
 Long version:
@@ -87,10 +87,10 @@ Named: `hotfix-{versionNumber}` eg `hotfix-1.2`
 
 `branchVersion` => the SemVer extracted from `targetBranch.Name`
 
-*   major: `mergeVersion.Major`
-*   minor: `mergeVersion.Minor`
-*   patch: `mergeVersion.Patch`
-*   pre-release: `beta{n}` where n = number of commits on branch  ('0' padded to
+* major: `mergeVersion.Major`
+* minor: `mergeVersion.Minor`
+* patch: `mergeVersion.Patch`
+* pre-release: `beta{n}` where n = number of commits on branch  ('0' padded to
     4 characters)
 
 Long version:
@@ -102,20 +102,20 @@ Long version:
 
 ### Release branches
 
-*   May branch off from: develop
-*   Must merge back into: develop and main
-*   Branch naming convention: `release-{n}` eg `release-1.2`
+* May branch off from: develop
+* Must merge back into: develop and main
+* Branch naming convention: `release-{n}` eg `release-1.2`
 
 `releaseVersion` => the SemVer extracted from `targetBranch.Name`
 `releaseTag` => the first version tag placed on the branch. Note that at least
 one version tag is required on the branch. The recommended initial tag is
 `{releaseVersion}.0-alpha1`. So for a branch named `release-1.2` the recommended
 tag would be `1.2.0-alpha1`
 
-*   major: `mergeVersion.Major`
-*   minor: `mergeVersion.Minor`
-*   patch: 0
-*   pre-release: `{releaseTag.preRelease}.{n}` where n = 1 + the number of commits
+* major: `mergeVersion.Major`
+* minor: `mergeVersion.Minor`
+* patch: 0
+* pre-release: `{releaseTag.preRelease}.{n}` where n = 1 + the number of commits
     since `releaseTag`.
 
 So on a branch named `release-1.2` with a tag `1.2.0-alpha1` and 4 commits after
@@ -139,10 +139,10 @@ Branch naming convention: anything except `main`, `develop`, `release-{n}`, or
 TODO: feature branches cannot start with a SemVer. to stop people from create
 branches named like "4.0.3"
 
-*   major: `mainMergeVersion.Major`
-*   minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
-*   patch: 0
-*   pre-release: `alpha.feature-{n}` where n = First 8 characters of the commit
+* major: `mainMergeVersion.Major`
+* minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
+* patch: 0
+* pre-release: `alpha.feature-{n}` where n = First 8 characters of the commit
     SHA of the first commit
 
 Long version:
@@ -159,10 +159,10 @@ Must merge back into: `develop`
 Branch naming convention: anything except `main`, `develop`, `release-{n}`, or
 `hotfix-{n}`. Canonical branch name contains `/pull/`.
 
-*   major: `mainMergeVersion.Major`
-*   minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
-*   patch: 0
-*   pre-release: `alpha.pull{n}` where n = the pull request number  ('0' padded to
+* major: `mainMergeVersion.Major`
+* minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
+* patch: 0
+* pre-release: `alpha.pull{n}` where n = the pull request number  ('0' padded to
     4 characters)
 
 ## Nightly Builds

docs/input/docs/learn/branching-strategies/githubflow/index.md

@@ -11,19 +11,19 @@ are much better off with a simpler workflow.
 
 GitHubFlow is in a nutshell:
 
-1.  Update main to latest [upstream](/docs/learn/git-setup#upstream) code
-2.  Create a feature branch `git checkout -b myFeatureBranch`
-3.  Do the feature/work
-4.  Push feature branch to [origin](/docs/learn/git-setup#origin)
-5.  Create pull request from origin/<featureBranch> -> upstream/main
-6.  Review, fix raised comments, merge your PR or even better, get someone else to.
+1. Update main to latest [upstream](/docs/learn/git-setup#upstream) code
+2. Create a feature branch `git checkout -b myFeatureBranch`
+3. Do the feature/work
+4. Push feature branch to [origin](/docs/learn/git-setup#origin)
+5. Create pull request from origin/<featureBranch> -> upstream/main
+6. Review, fix raised comments, merge your PR or even better, get someone else to.
 
 The main rule of GitHub Flow is that main should _always_ be deployable.
 GitHub Flow allows and encourages [continuous delivery](/docs/reference/modes/continuous-delivery).
 
 ## Resources
 
-*   [GitHubFlow guide by GitHub](https://docs.github.com/en/get-started/quickstart/github-flow#introduction)
-*   [GitHubFlow original blog post](https://scottchacon.com/2011/08/31/github-flow)
-*   [Phil Haack's (haacked) GitHubFlow aliases](https://haacked.com/archive/2014/07/28/github-flow-aliases/)
-*   [GitHubFlow vs GitFlow](https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/)
+* [GitHubFlow guide by GitHub](https://docs.github.com/en/get-started/quickstart/github-flow#introduction)
+* [GitHubFlow original blog post](https://scottchacon.com/2011/08/31/github-flow)
+* [Phil Haack's (haacked) GitHubFlow aliases](https://haacked.com/archive/2014/07/28/github-flow-aliases/)
+* [GitHubFlow vs GitFlow](https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/)