More links fixed

Author: JakeGinnivan

docs/git-branching-strategies/githubflow.md

@@ -3,14 +3,14 @@ GitHub Flow is a simple and effective branching strategy which the folks at GitH
 
 GitHub Flow is in a nutshell:
 
-1) Update master to latest [upstream](../Reference/gitSetup.md#upstream) code
+1) Update master to latest [upstream](../reference/git-setup.md#upstream) code
 2) Create a feature branch `git checkout -b myFeatureBranch`
 3) Do the feature/work
-4) Push feature branch to [origin](../Reference/gitSetup.md#origin)
+4) Push feature branch to [origin](../reference/git-setup.md#origin)
 5) Create pull request from origin/<featureBranch> -> upstream/master
 6) Review, fix raised comments, merge your PR or even better, get someone else to.
 
-The main rule of GitHub Flow is that master should *always* be deployable. GitHub Flow allows and encourages [continuous deliver](../Reference/Continuous-Delivery.md).
+The main rule of GitHub Flow is that master should *always* be deployable. GitHub Flow allows and encourages [continuous deliver](../reference/continuous-delivery.md).
 
 ## Resources
  - [GitHubFlow guide by GitHub](https://guides.github.com/introduction/flow/index.html)

docs/git-branching-strategies/index.md

@@ -6,14 +6,14 @@ When building GitVersion we had to work through not only how to use the branchin
 ## Introduction to branching strategies
 Git is a very powerful tool and if you do not settle on a branching strategy and 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 and GitFlow.
+As mentioned above the GitVersion docs cover [GitHubFlow](githubflow.md) and [GitFlow](gitflow.md).
 
 ### GitHubFlow
 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/mainline-development.md) on `master`
- - Work on [feature branches](../Reference/featureBranches.md), merge into `master` via [pull requests](../Reference/pull-requests.md)
- - Works well for [continuous delivery](../Reference/Continuous-Delivery.md)
+ - [Mainline development](../reference/mainline-development.md) on `master`
+ - Work on [feature branches](../reference/feature-branches.md), merge into `master` via [pull requests](../reference/pull-requests.md)
+ - Works well for [continuous delivery](../reference/continuous-delivery.md)
  - Does not have a way to manage/maintain old releases
  - Only allows working on a single release at a time
 
@@ -32,4 +32,4 @@ There are a few reasons you would pick GitFlow over GitHubFlow, they are:
 2) You need to work on multiple releases at the same time
  - For example a new feature which will go in the next major version, while bug 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](convertingToGitFlow.md)
+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.md)

docs/usage.md

@@ -16,9 +16,9 @@ Available on [Chocolatey](http://chocolatey.org) under [GitVersion.Portable](htt
 Switches are available with `GitVersion /?`
 
 ### Output
-By default GitVersion returns a json object to stdout containing all the [variables](variables.md) which GitVersion generates. This works great if you want to get your build scripts to parse the json object then use the variables, but there is a simpler way.
+By default GitVersion returns a json object to stdout containing all the [variables](more-info/variables.md) which GitVersion generates. This works great if you want to get your build scripts to parse the json object then use the variables, but there is a simpler way.
 
-`GitVersion.exe /output buildserver` will change the mode of GitVersion to write out the variables to whatever build server it is running in. You can then use those variables in your build scripts or run different tools to create versioned NuGet packages or whatever you would like to do. See [build servers](buildServers.md) for more information about this.
+`GitVersion.exe /output buildserver` will change the mode of GitVersion to write out the variables to whatever build server it is running in. You can then use those variables in your build scripts or run different tools to create versioned NuGet packages or whatever you would like to do. See [build servers](build-server-support.md) for more information about this.
 
 
 ## MSBuild Task
@@ -45,7 +45,7 @@ Make sure there is a tag somewhere on master named `v1.2.3` before `HEAD` (chang
 
 Continue working as usual and when you release/deploy, tag the branch/release `v1.2.4`.
 
-If you want to bump up the major or minor version, create a text file in the root directory named NextVersion.txt and inside of it on a single line enter the version number that you want your next release to be.  e.g., `2.0`.
+If you want to bump up the major or minor version, create a `GitVersionConfig.yaml` file in the root of your repo and inside of it on a single line enter `next-version: <version you want>`, for example `next-version: 3.0.0`
 
 ### Why is AssemblyVersion only set to Major.Minor?