updated docs to use main instead of master

Author: arturcic

docs/input/docs/build-server-support/build-server/azure-devops.md

@@ -33,7 +33,7 @@ other build steps.
 5. If you want the GitVersionTask to update AssemblyInfo files add
 `updateAssemblyInfo true` to the Arguments parameter.
 6. If you want to update the build number you need to send a
-[logging command](https://github.com/Microsoft/azure-pipelines-tasks/blob/master/docs/authoring/commands.md)
+[logging command](https://github.com/Microsoft/azure-pipelines-tasks/blob/main/docs/authoring/commands.md)
 to TFS.
 
 ### Using the custom GitVersion build step
@@ -53,12 +53,12 @@ to install the GitVersion extension:
 If you run TFS 2015 RTM or Update 1 or don't want to install the GitVersion
 extension you can install the build task manually:
 
-1. Install the `tfx` command line tool as shown [here](https://github.com/Microsoft/tfs-cli/blob/master/README.md#install).
-2. For TFS 2015 On-Prem configure Basic Authentication in TFS as shown [here](https://github.com/Microsoft/tfs-cli/blob/master/docs/configureBasicAuth.md).
+1. Install the `tfx` command line tool as shown [here](https://github.com/Microsoft/tfs-cli/blob/main/README.md#install).
+2. For TFS 2015 On-Prem configure Basic Authentication in TFS as shown [here](https://github.com/Microsoft/tfs-cli/blob/main/docs/configureBasicAuth.md).
 3. Download the GitVersion TFS build task from the latest release on the
 [GitVersion releases page](https://github.com/GitTools/GitVersion/releases) and
 unzip.
-4. Run `tfx login` as shown [here](https://github.com/Microsoft/tfs-cli/blob/master/README.md#login).
+4. Run `tfx login` as shown [here](https://github.com/Microsoft/tfs-cli/blob/main/README.md#login).
 5. From the directory outside of where you unzipped the task, run
 `tfx build tasks upload --task-path .\GitVersionVsixTask --overwrite` where
 GitVersionVsixTask is the directory containing the files.

docs/input/docs/build-server-support/build-server/octopus-deploy.md

@@ -47,10 +47,10 @@ manual build in your *build server* which pushes the package to Octopus deploy.
 
 Another simple option is to tag a stable version to release, the basic idea is:
 
-1. GitVersion is set to continuous deployment mode, so master will create `-ci.x`
+1. GitVersion is set to continuous deployment mode, so main will create `-ci.x`
 pre-release builds
 1. CI Builds only create NuGet packages for stable builds
-1. You tag master with a stable version of the next version then push it
+1. You tag main with a stable version of the next version then push it
 1. The CI build triggers, GitVersion will always respect tags so you will get a
 stable version
 1. The stable package will be pushed to Octopus
@@ -98,8 +98,8 @@ if ($pendingChanges -ne $null)
 
 # Pull latest, fast-forward only so that it git stops if there is an error
 & git fetch origin
-& git checkout master
-& git merge origin/master --ff-only
+& git checkout main
+& git merge origin/main --ff-only
 
 # Determine version to release
 $output = & $gitversion /output json
@@ -118,7 +118,7 @@ if ($LASTEXITCODE -ne 0) {
     throw "No changes detected since last release"
 }
 
-& git push origin master --tags
+& git push origin main --tags
 
 Pop-Location
 ```

docs/input/docs/build-server-support/build-server/teamcity.md

@@ -81,18 +81,18 @@ variables because teamcity will pass them through automatically.
 
 ### When TeamCity -> GitHub can't use https
 
-GitVersion requires the presence of master branch in order to determine the
+GitVersion requires the presence of main branch in order to determine the
 version number.  If TeamCity uses https to clone git repos then GitVersion will
-pull down master branch for you during the build.
+pull down main branch for you during the build.
 
 If however your TeamCity uses SSH to clone git repos and https is unavailable
 then GitVersion will error with a message like
 
 > [GitVersionTask.UpdateAssemblyInfo] Error occurred: GitVersion.MissingBranchException:
 Could not fetch from '[email protected]:Xero/Bus.git' since LibGit2 does
 not support the transport. You have most likely cloned using SSH. If there is a
-remote branch named 'master' then fetch it manually, otherwise please create a
-local branch named 'master'. ---> LibGit2Sharp.LibGit2SharpException: An error
+remote branch named 'main' then fetch it manually, otherwise please create a
+local branch named 'main'. ---> LibGit2Sharp.LibGit2SharpException: An error
 was raised by libgit2. Category = Net (Error). This transport isn't implemented.
 Sorry
 

docs/input/docs/configuration.md

@@ -65,7 +65,7 @@ And the description of the available options are:
 
 ### next-version
 
-Allows you to bump the next version explicitly, useful for bumping `master` or a
+Allows you to bump the next version explicitly, useful for bumping `main` or a
 feature with breaking changes a major increment.
 
 ### assembly-versioning-scheme
@@ -148,7 +148,7 @@ continuous-delivery-fallback-tag: ''
 ...
 ```
 
-Doing so can be helpful if you use your `master` branch as a `release` branch.
+Doing so can be helpful if you use your `main` branch as a `release` branch.
 
 ### tag-prefix
 
@@ -282,7 +282,7 @@ upgrade.
 
 ```yaml
 branches:
-  master:
+  main:
     regex: ^master$|^main$
     mode: ContinuousDelivery
     tag: ''
@@ -373,18 +373,18 @@ Take this commit graph
 |/
 *
 *
-* (master)
+* (main)
 ```
 
 By looking at this graph, you cannot tell which of these scenarios happened:
 
 + feature/foo branches off release/1.0.0
-  + Branch release/1.0.0 from master
+  + Branch release/1.0.0 from main
   + Branch feature/foo from release/1.0.0
   + Add a commit to both release/1.0.0 and feature/foo
   + release/1.0.0 is the base for feature/foo
 + release/1.0.0 branches off feature/foo
-  + Branch feature/foo from master
+  + Branch feature/foo from main
   + Branch release/1.0.0 from feature/foo
   + Add a commit to both release/1.0.0 and feature/foo
   + feature/foo is the base for release/1.0.0
@@ -397,7 +397,7 @@ by telling it what types of branches a branch can be created from. For example,
 feature branches are, by default, configured to have the following source
 branches:
 
-`source-branches: ['master', 'develop', 'feature', 'hotfix', 'support']`
+`source-branches: ['main', 'develop', 'feature', 'hotfix', 'support']`
 
 This means that we will never bother to evaluate pull request branches as merge
 base options and being explicit in this way also improves the performance of
@@ -420,7 +420,7 @@ A complete example:
 branches:
   unstable:
     regex: ...
-    is-source-branch-for: ['master', 'develop', 'feature', 'hotfix', 'support']
+    is-source-branch-for: ['main', 'develop', 'feature', 'hotfix', 'support']
 ```
 
 Without this configuration value you would have to do:
@@ -460,7 +460,7 @@ Same as for the [global configuration, explained above](#increment).
 
 ### prevent-increment-of-merged-branch-version
 
-When `release-2.0.0` is merged into master, we want master to build `2.0.0`. If
+When `release-2.0.0` is merged into main, we want main to build `2.0.0`. If
 `release-2.0.0` is merged into develop we want it to build `2.1.0`, this option
 prevents incrementing after a versioned branch is merged.
 
@@ -494,7 +494,7 @@ branches:
 ### track-merge-target
 
 Strategy which will look for tagged merge commits directly off the current
-branch. For example `develop` → `release/1.0.0` → merge into `master` and tag
+branch. For example `develop` → `release/1.0.0` → merge into `main` and tag
 `1.0.0`. The tag is *not* on develop, but develop should be version `1.0.0` now.
 
 ### tracks-release-branches
@@ -508,7 +508,7 @@ Indicates this branch config represents a release branch in GitFlow.
 ### is-mainline
 
 When using Mainline mode, this indicates that this branch is a mainline. By
-default support/ and master are mainlines.
+default support/ and main are mainlines.
 
 ### pre-release-weight
 

docs/input/docs/examples.md

@@ -15,14 +15,14 @@ adb29a -> 1.0.1-feature-foo.1+1 (PR #5 Version: `1.0.1-PullRequest.5+2`)
 5f413b -> 1.0.1+4
 d6155b -> 2.0.0-rc.1+0 (Before and after tag)
 d53ab6 -> 2.0.0-rc.2+1 (Pre-release number was bumped because of the tag on previous commit)
-b5d142 -> 2.0.0+0 (2.0.0 branch was merged, so master is now at 2.0.0)
+b5d142 -> 2.0.0+0 (2.0.0 branch was merged, so main is now at 2.0.0)
 ```
 
 This is just a small sample of the way GitVersion works. The idea is you just
 plug it in and you will get sensible version numbers by default. We support the
 following branch types ootb:
 
-- master
+- main
 - develop
 - hotfix/
 - feature/

docs/input/docs/git-branching-strategies/converting-to-gitflow.md

@@ -7,7 +7,7 @@ Converting to GitFlow is simple. Whenever you need to convert, simply do the
 following
 
 ```shell
-git checkout master
+git checkout main
 git checkout -b develop
 git push upstream develop
 ```

docs/input/docs/git-branching-strategies/creating-updating-examples.md

@@ -16,4 +16,4 @@ 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
 recorded perform the action directly on the repository (`fixture.Repository.`)
 
-The tests for the examples should all live at [DocumentationSamples.cs](https://github.com/GitTools/GitVersion/blob/master/src/GitVersion.Core.Tests/IntegrationTests/DocumentationSamples.cs)
+The tests for the examples should all live at [DocumentationSamples.cs](https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.Core.Tests/IntegrationTests/DocumentationSamples.cs)

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

@@ -40,15 +40,15 @@ 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
-are always created off `master`
+are always created off `main`
 
 ![GitFlow](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 `master`. Finally `master` is tagged with the released version.
+`develop` and `main`. Finally `main` is tagged with the released version.
 
 ![GitFlow](img/6d33d35a70a777608fa1_minor-release.png)
 

docs/input/docs/git-branching-strategies/gitflow.md

@@ -11,15 +11,15 @@ SemVer compatible versions from this structure.
 ## Assumptions:
 
 * Using [GitFlow branching model](http://nvie.com/git-model/) which always has a
-master and a develop branch
+main and a develop branch
 * Following [Semantic Versioning](http://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](http://nvie.com/posts/a-successful-git-branching-model/)
 specifies branches with a "-" separator while the [git flow extensions](https://github.com/nvie/gitflow)
 default to a "/" separator.  Either work with GitVersion.
-* Tags are used on the master 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
 over to GitVersion
@@ -34,9 +34,9 @@ will refer to:
 * `targetBranch` => the branch we are targeting
 * `targetCommit` => the commit we are targeting on `targetbranch`
 
-### Master branch
+### Main branch
 
-Commits on master will always be a merge commit (Either from a `hotfix` or a
+Commits on main will always be a merge commit (Either from a `hotfix` or a
 `release` branch) or a tag. As such we can simply take the commit message or tag
 message.
 
@@ -62,15 +62,15 @@ Long version:
 ### Develop branch
 
 `targetCommitDate` => the date of the `targetCommit`
-`masterVersionCommit` => the first version (merge commit or SemVer tag) on
-`master` that is older than the `targetCommitDate`
-`masterMergeVersion` => the SemVer extracted from `masterVersionCommit.Message`
+`mainVersionCommit` => the first version (merge commit or SemVer tag) on
+`main` that is older than the `targetCommitDate`
+`mainMergeVersion` => the SemVer extracted from `mainVersionCommit.Message`
 
-* major: `masterMergeVersion.Major`
-* minor: `masterMergeVersion.Minor + 1` (0 if the override above is used)
+* 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
-`masterVersionCommit.Date` ('0' padded to 4 characters)
+`mainVersionCommit.Date` ('0' padded to 4 characters)
 
 Long version:
 
@@ -97,7 +97,7 @@ Long version:
 ### Release branches
 
  * May branch off from: develop
- * Must merge back into: develop and master
+ * Must merge back into: develop and main
  * Branch naming convention: `release-{n}` eg `release-1.2`
 
 `releaseVersion` => the SemVer extracted from `targetBranch.Name`
@@ -125,14 +125,14 @@ Long version:
 
 May branch off from: `develop`
 Must merge back into: `develop`
-Branch naming convention: anything except `master`, `develop`, `release-{n}`, or
+Branch naming convention: anything except `main`, `develop`, `release-{n}`, or
 `hotfix-{n}`.
 
 TODO: feature branches cannot start with a SemVer. to stop people from create
 branches named like "4.0.3"
 
-* major: `masterMergeVersion.Major`
-* minor: `masterMergeVersion.Minor + 1` (0 if the override above is used)
+* 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
@@ -146,11 +146,11 @@ Long version:
 
 May branch off from: `develop`
 Must merge back into: `develop`
-Branch naming convention: anything except `master`, `develop`, `release-{n}`, or
+Branch naming convention: anything except `main`, `develop`, `release-{n}`, or
 `hotfix-{n}`. Canonical branch name contains `/pull/`.
 
-* major: `masterMergeVersion.Major`
-* minor: `masterMergeVersion.Minor + 1` (0 if the override above is used)
+* 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)

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

@@ -15,7 +15,7 @@ Title: GitHubFlow Examples
 
 Release branches can be used in GitHubFlow as well as GitFlow. Sometimes you
 want to start on a large feature which may take a while to stabilise so you want
-to keep it off master. In these scenarios you can either create a long lived
+to keep it off main. In these scenarios you can either create a long lived
 feature branch (if you do not know the version number this large feature will go
 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