Fix links

Author: asbjornu

BREAKING_CHANGES.md

@@ -42,6 +42,6 @@ work for you
   `GitVersionConfig.yaml` instead
 - GitVersionTask's `ReleaseDateAttribute` no longer exists
 
-[gitflow]: https://gitversion.net/docs/git-branching-strategies/gitflow-examples_complete
+[gitflow]: https://gitversion.net/docs/learn/branching-strategies/gitflow-examples_complete
 [pr-1541]: https://github.com/GitTools/GitVersion/pull/1541
 [pr-1581]: https://github.com/GitTools/GitVersion/pull/1581

CONTRIBUTING.md

@@ -5,7 +5,7 @@ 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.readthedocs.org/en/latest/more-info/how-it-works/#architecture) and how [we write tests](#writing-tests)
+- 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.
@@ -23,7 +23,7 @@ Issues are also welcome, [failing tests](#writing-tests) are even more welcome.
 
 ## How it works
 
-See [how it works](http://gitversion.readthedocs.org/en/latest/more-info/how-it-works/) in GitVersion's documentation
+See [how it works](http://gitversion.net/docs/learn/how-it-works/) in GitVersion's documentation
 
 ## Writing Tests
 

README.md

@@ -84,7 +84,7 @@ from The Noun Project.
 [contribute]:                      https://github.com/GitTools/GitVersion/blob/main/CONTRIBUTING.md
 [why]:                             https://gitversion.net/docs/why
 [usage]:                           https://gitversion.net/docs/usage/usage
-[how]:                             https://gitversion.net/docs/more-info/how-it-works
+[how]:                             https://gitversion.net/docs/learn/how-it-works
 [faq]:                             https://gitversion.net/docs/faq
 [who]:                             https://gitversion.net/docs/who
 [gv-in-action]:                    https://raw.github.com/GitTools/GitVersion/master/docs/input/docs/img/README.png

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

@@ -1,6 +1,7 @@
 ---
 Order: 70
-Title: Creating/Updating Examples
+Title: Contribute Examples
+Description: Contribute examples of how GitVersion works for your branching strategy
 ---
 
 The examples are generated by GitVersion tests, there are a number of services

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

@@ -4,20 +4,20 @@ Title: GitFlow Examples
 ---
 
 These examples are using the *default* configuration with GitVersion. Which is
-[continuous deployment](../reference/versioning-modes/continuous-deployment) mode for
-`develop` and [continuous delivery](../reference/versioning-modes/continuous-delivery) mode
+[continuous deployment](/docs/reference/modes/continuous-deployment) mode for
+`develop` and [continuous delivery](/docs/reference/modes/continuous-delivery) mode
 for all other branches.
 
 This default configuration allows you to publish CI builds from develop to a CI
 MyGet feed, or another CI feed. Then all other branches are manually released
-then tagged. Read more about this at [version increments](../more-info/version-increments).
+then tagged. Read more about this at [version increments](/docs/reference/version-increments).
 
 ## Feature Branches
 
 Feature branches will take the feature branch name and use that as the
 pre-release tag.
 
-![GitFlow](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*
@@ -35,29 +35,29 @@ commit, the following commit would increase to `-beta.2`.
 Because feature branches are most likely pushed to a fork, we are showing the
 pull request branch name which is created when you submit a pull request
 
-![GitFlow](img/09fdf46995b771f3164a_pull-request.png)
+![GitFlow](/docs/img/09fdf46995b771f3164a_pull-request.png)
 
 ## Hotfix Branches
 
 Hotfix branches are used when you need to do a *patch* release in GitFlow and
 are always created off `main`
 
-![GitFlow](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](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](img/39f9d8b8b007c82f1f80_major-release.png)
+![GitFlow](/docs/img/39f9d8b8b007c82f1f80_major-release.png)
 
 ## Support Branches
 
@@ -74,12 +74,21 @@ 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](img/b035b8ca99bd34239518_support-hotfix.png)
+![GitFlow](/docs/img/b035b8ca99bd34239518_support-hotfix.png)
 
 ### Minor Release
 
-![GitFlow](img/2167fb1c4a5cf84edfd8_support-minor.png)
+![GitFlow](/docs/img/2167fb1c4a5cf84edfd8_support-minor.png)
 
-## To Update/Contribute
+## To Contribute
 
-See [creating/updating examples](creating-updating-examples)
+See [contributing examples](/docs/learn/branching-strategies/contribute-examples).
+
+## Complete Example
+
+![GitFlow](http://uml.mvnsearch.org/gist/cf053d7f5d336ae9f7bb)
+
+### Source
+
+See `DocumentationSamples.GitFlowExample`. To update, modify then run test.
+Update [https://gist.github.com/JakeGinnivan/cf053d7f5d336ae9f7bb](https://gist.github.com/JakeGinnivan/cf053d7f5d336ae9f7bb)

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

@@ -1,9 +1,10 @@
 ---
 Order: 20
-Title: GitFlow
+Title: Git Flow
+Description: The Git Flow branching strategy allows for more structured releases
 ---
 
-GitFlow allows more structured releases, and GitVersion will derive sensible
+Git Flow allows more structured releases, and GitVersion will derive sensible
 SemVer compatible versions from this structure.
 
 ## Resources

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

@@ -5,11 +5,11 @@ Title: GitHubFlow Examples
 
 ## Feature branch
 
-![GitHubFlow](img/githubflow_feature-branch.png)
+![GitHubFlow](/docs/img/githubflow_feature-branch.png)
 
 ## Pull requests
 
-![GitHubFlow](img/githubflow_pull-request.png)
+![GitHubFlow](/docs/img/githubflow_pull-request.png)
 
 ## Release branch
 
@@ -21,4 +21,4 @@ into, and it's non-breaking) otherwise you can create a release branch for the
 next major version. You can then submit pull requests to the long lived feature
 branch or the release branch.
 
-![GitFlow](img/githubflow_release-branch.png)
+![GitFlow](/docs/img/githubflow_release-branch.png)

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

@@ -1,6 +1,7 @@
 ---
 Order: 30
-Title: GitHubFlow
+Title: GitHub Flow
+Description: GitHub flow is a simpler and pull request-driven branching strategy
 ---
 
 GitHubFlow is a simple and effective branching strategy which the folks at
@@ -9,15 +10,15 @@ are much better off with a simpler workflow.
 
 GitHubFlow is in a nutshell:
 
-1. Update main to latest [upstream](../reference/git-setup#upstream) code
+1. Update main to latest [upstream](/docs/learn/git-setup#upstream) code
 1. Create a feature branch `git checkout -b myFeatureBranch`
 1. Do the feature/work
-1. Push feature branch to [origin](../reference/git-setup#origin)
+1. Push feature branch to [origin](/docs/learn/git-setup#origin)
 1. Create pull request from origin/<featureBranch> -> upstream/main
 1. 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](../reference/versioning-modes/continuous-delivery).
+GitHub Flow allows and encourages [continuous delivery](/docs/reference/modes/continuous-delivery).
 
 ## Resources
 

docs/input/docs/learn/branching-strategies/overview.md

@@ -1,6 +1,7 @@
 ---
 Order: 10
-Title: Home
+Title: Overview
+Description: An overview of the different branching strategies supported by GitVersion
 ---
 
 There are two mainstream branching strategies in git and many lesser known
@@ -17,22 +18,22 @@ associated workflows then you will likely lose work at some point. At the start
 of any project I recommend picking a branching strategy and making sure your
 whole team understands it.
 
-As mentioned above the GitVersion docs cover [GitHubFlow](githubflow) and
-[GitFlow](gitflow).
+As mentioned above the GitVersion docs cover [GitHubFlow][githubflow] and
+[GitFlow][gitflow].
 
-### GitHubFlow
+### GitHub Flow
 
 GitHubFlow is a simple and powerful branching strategy. It is what GitHub uses
 and the branching strategy most open source projects use.
 
- - [Mainline development](../reference/versioning-modes/mainline-development) on `main`
- - Work on [feature branches](../reference/feature-branches), merge into
-`main` via [pull requests](../reference/pull-requests)
- - Works well for [continuous delivery](../reference/versioning-modes/continuous-delivery)
+ - [Mainline development][mainline] on `main`
+ - Work on [feature branches][feature-branches], merge into `main` via [pull
+   requests][pull-requests]
+ - Works well for [continuous delivery][continuous-delivery]
  - Does not have a way to manage/maintain old releases
  - Only allows working on a single release at a time
 
-### GitFlow
+### Git Flow
 
 GitFlow is a more complex and complete branching strategy. It also gives much
 more control over when features and code is released.
@@ -55,4 +56,12 @@ fixes/smaller features are still going into the current release
 
 But if you do not have a good reason to go with GitFlow, then start with
 GitHubFlow. It is a far simpler model and if you end up needing GitFlow later,
-it is [easy to convert](converting-to-gitflow)
+it is [easy to convert][converting-to-gitflow].
+
+[continuous-delivery]: /docs/reference/modes/continuous-delivery
+[converting-to-gitflow]: /docs/learn/branching-strategies/gitflow/converting-to-gitflow
+[feature-branches]: /docs/learn/branching-strategies/gitflow/examples#feature-branches
+[gitflow]: /docs/learn/branching-strategies/gitflow
+[githubflow]: /docs/learn/branching-strategies/githubflow
+[mainline]: /docs/reference/modes/mainline
+[pull-request]: /docs/learn/branching-strategies/gitflow/examples#pull-requests

docs/input/docs/learn/faq.md

@@ -6,28 +6,28 @@ Title: FAQ
 ## Why is my version not incrementing?
 
 GitVersion calculates the semantic version, this will only change once per
-*release*. Read more at [version increments](more-info/version-increments)
+*release*. Read more at [version increments](/docs/reference/version-increments)
 
 ## I'm using Octopus deploy
 
 Because Octopus deploy cannot have the same version of a package to a NuGet
 feed. There is no magic solution to this, but you can read more about your
-options at [octopus deploy](build-server-support/build-server/octopus-deploy).
+options at [octopus deploy](/docs/reference/build-servers/octopus-deploy).
 
 ## How can GitVersion run for a shallow clone or checkout on server working directories
 
 GitVersion needs a proper git repository to run, some build servers do not do a
 proper clone which can cause issues. GitVersion has a feature called
-[dynamic repositories](more-info/dynamic-repositories) which solves this by
+[dynamic repositories](/docs/learn/dynamic-repositories) which solves this by
 cloning the repository and working against that clone instead of the working
 directory.
 
 ## I don't understand what SemVer is all about
 
 Not a problem, we have a quick introduction to SemVer which can be a good primer
-to read before reading [SemVer.org](http://semver.org)
+to read before reading [SemVer.org](https://semver.org)
 
-Read more at [intro to semver](reference/intro-to-semver)
+Read more at [intro to semver](/docs/learn/intro-to-semver)
 
 ## I can't use the build number for NuGet
 

docs/input/docs/learn/how-it-works.md

@@ -7,7 +7,7 @@ GitVersion v3 works very differently to v2. Version 2 had knowledge of both
 GitFlow and GitHubFlow hard coded into it, with each branch having it's own
 class which calculated the version for that branch type.
 
-v3 is driven by [configuration](../configuration), meaning most of the
+v3 is driven by [configuration](/docs/reference/configuration), meaning most of the
 behaviors in GitVersion can be tweaked to work the way you want. This also makes
 it *much* more predictable and easier to diagnose when odd things are happening.
 

docs/input/docs/learn/intro-to-semver.md

@@ -28,4 +28,4 @@ For a more complete explanation check out [semver.org](http://semver.org) which
 ## SemVer in GitVersion
 GitVersion makes it easy to follow semantic versioning in your library by automatically calculating the next semantic version which your library/application is likely to use. In [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/) the develop branch will bump the *minor* when main is tagged, while [GitHubFlow](https://guides.github.com/introduction/flow/) will bump the *patch*.
 
-Because one size does not always fit all, GitVersion provides many [Variables](../more-info/variables) for you to use which contain different variations of the version. For example SemVer will be in the format `{major}.{minor}.{patch}-{tag}`, but `FullSemVer` will also include build metadata: `{major}.{minor}.{patch}-{tag}+{buildmetadata}`
+Because one size does not always fit all, GitVersion provides many [Variables](/docs/reference/variables) for you to use which contain different variations of the version. For example SemVer will be in the format `{major}.{minor}.{patch}-{tag}`, but `FullSemVer` will also include build metadata: `{major}.{minor}.{patch}-{tag}+{buildmetadata}`

docs/input/docs/reference/build-servers/azure-devops.md

@@ -20,8 +20,8 @@ task into your TFS or Azure DevOps Pipeline instance.
 1. Add the [GitVersionTask](https://www.nuget.org/packages/GitVersionTask/)
 NuGet package to your projects.
 
-See [MSBuild Task](../../usage/msbuild-task) for further instructions how to use the
-MS Build Task.
+See [MSBuild Task](/docs/usage/msbuild) for further instructions how to use
+the MS Build Task.
 
 ### Using GitVersion with the Command Line build step
 
@@ -125,7 +125,7 @@ To use these variables you can just refer to them using the standard variable
 syntax. For instance `$(GitVersion.NuGetVersion)` in your nuget pack task to set
 the version number. Since update 1 there are no known limitations.
 
-See [Variables](../../more-info/variables) for an overview of available variables.
+See [Variables](/docs/reference/variables) for an overview of available variables.
 
 #### Using GitVersion variables in build name
 
@@ -145,7 +145,7 @@ If you currently use `$(rev:.r)` in your build number, that won't
 work correctly if you
 use GitVersion variables as well due to the delayed expansion of the GitVersion
 vars. Instead, you might be able to use `$(GitVersion_BuildMetaData)` to achieve
-a similar result.  See [Variables](../../more-info/variables) for more info on the
+a similar result.  See [Variables](/docs/reference/variables) for more info on the
 variables.
 :::
 

docs/input/docs/reference/build-servers/gitlab.md

@@ -4,5 +4,6 @@ Title: GitLab CI
 Description: Details on the GitLab CI support in GitVersion
 ---
 
-To use GitVersion with GitLab CI, either use the [MSBuild Task](../../usage/msbuild-task)
-or put the GitVersion executable in your runner's `PATH`.
+To use GitVersion with GitLab CI, either use the [MSBuild
+Task](/docs/usage/msbuild) or put the GitVersion executable in your
+runner's `PATH`.

docs/input/docs/reference/build-servers/index.cshtml

@@ -1,6 +1,6 @@
 ---
 Order: 3000
-Description: Build Servers
+Description: Details on GitVersion's Build Server support
 ---
 
 <p>
@@ -34,7 +34,7 @@ Description: Build Servers
 
 <p>
     When running in MSBuild either from the
-    <a href="../usage/msbuild-task">MSBuild Task</a> or
+    <a href="/docs/usage/msbuild">MSBuild Task</a> or
     by using the <code>/proj myproject.sln</code> parameter, GitVersion will
     make the MSBuild variables available in the format
     <code>$(GitVersion_SemVer)`</code>

docs/input/docs/reference/build-servers/octopus-deploy.md

@@ -7,16 +7,16 @@ Description: Details on the Octopus Deploy support in GitVersion
 While not a build server, there are a few things to consider when using Octopus
 Deploy with GitVersion.
 
- GitVersion follows [continuous delivery](../../reference/versioning-modes/continuous-delivery)
- versioning by default. This means builds will keep producing *the same version*
- with just metadata differing. For example, when you start a new release (say
- `1.0.0`) with git flow, the branch will start with a semver like
- `1.0.0-beta.1+0`, and the Octopus NuGet package will have a version of
- `1.0.0-beta0001`. As you commit changes to this release branch the *metadata*
- of the semver will increase like so: `1.0.0-beta.1+1`, `1.0.0-beta.1+2`, etc.
- However, the version of the corresponding Octopus NuGet package will retain the
- *same* `1.0.0-beta0001` version you started with. The problem is Octopus Deploy
- will prevent you from deploying these revisions because it sees the same NuGet
+ GitVersion follows [continuous delivery][continuous-delivery] versioning by
+ default. This means builds will keep producing *the same version* with just
+ metadata differing. For example, when you start a new release (say `1.0.0`)
+ with git flow, the branch will start with a semver like `1.0.0-beta.1+0`, and
+ the Octopus NuGet package will have a version of `1.0.0-beta0001`. As you
+ commit changes to this release branch the *metadata* of the semver will
+ increase like so: `1.0.0-beta.1+1`, `1.0.0-beta.1+2`, etc. However, the version
+ of the corresponding Octopus NuGet package will retain the *same*
+ `1.0.0-beta0001` version you started with. The problem is Octopus Deploy will
+ prevent you from deploying these revisions because it sees the same NuGet
  package version and thinks nothing has changed.
 
 Because Octopus Deploy uses NuGet like this you cannot continue to push
@@ -169,8 +169,11 @@ if ($versionInfo.PreReleaseTag -eq '')
 }
 ```
 
-### Configure GitVersion to [increment per commit](../../more-info/incrementing-per-commit)
+### Configure GitVersion to Increment Per Commit
 
-As mentioned above, this means you will burn multiple versions per release. This
-might not be an issue for you, but can confuse consumers of your library as the
-version has semantic meaning.
+As mentioned above, [incrementing per commit][increment-per-commit] means you
+will burn multiple versions per release. This might not be an issue for you, but
+can confuse consumers of your library as the version has semantic meaning.
+
+[continuous-delivery]: /docs/reference/modes/continuous-delivery
+[increment-per-commit]: /docs/reference/version-increments#incrementing-per-commit

docs/input/docs/reference/build-servers/teamcity.md

@@ -58,7 +58,7 @@ GitVersion. Server side checkout sends just the files to the agent and not the
 actual .git folder. Dynamic repositories will clone your repo into a temp folder
 and use it to calculate version information.
 
-See [dynamic repositories](../../more-info/dynamic-repositories) for more info.
+See [dynamic repositories](/docs/learn/dynamic-repositories) for more info.
 
 ### Output