renovatebot · rarkins · May 3, 2021 · May 1, 2021 · May 1, 2021 · May 1, 2021
diff --git a/docs/usage/automerge-configuration.md b/docs/usage/automerge-configuration.md
@@ -79,7 +79,7 @@ And this is especially so if your repository needs rebasing, e.g. because you us
 e.g. let's say you have dependencies `abc` and `xyz` with upgrades, and you use a `yarn.lock` file.
 
 - At the start of the schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates
-- After `abc` passes tests, `Renovate` will automerge it to `master`
+- After `abc` passes tests, `Renovate` will automerge it to `main`
 - The `xyz` branch probably now has `yarn.lock` conflicts
 - Renovate will immediately check all other branches and rebase them
 - The change to `xyz` branch will trigger another round of CI tests
@@ -98,7 +98,7 @@ For this reason we recommend you consider setting `automergeType=branch` which w
 
 Add the `renovate/**` branch to your testing workflow files, or Renovate will not work properly with the `automergeType=branch` setting.
 
-The result is that passing updates are essentially "silent" - the only sign of them are the commits to your `master` branch.
+The result is that passing updates are essentially "silent" - the only sign of them are the commits to your `main` branch.
 If you have enabled branch protection which prevents Renovate from automerging directly to the base branch, then this won't work and you should stick with the default PR-based automerging instead.
 
 ## Assignees and Reviewers

diff --git a/docs/usage/config-presets.md b/docs/usage/config-presets.md
@@ -122,7 +122,7 @@ Or if you think your preset would be valuable for others, please contribute a PR
 ## GitHub-hosted Presets
 
 It is also possible to host your preset config using just a regular GitHub repository and without needing to publish it to npmjs.
-In such cases Renovate will simply look for a renovate.json file in the default branch, e.g. master.
+In such cases Renovate will simply look for a `renovate.json` file in the default branch, e.g. `main`.
 
 To host your preset config on GitHub:
 
@@ -140,7 +140,7 @@ You do not need to add it as a devDependency or add any other files to the prese
 ## GitLab-hosted Presets
 
 It is also possible to host your preset config using just a regular GitLab repository and without needing to publish it to npmjs.
-In such cases Renovate will simply look for a renovate.json file in the default branch, (for now only the master branch is supported).
+In such cases Renovate will simply look for a `renovate.json` file in the default branch, (for now only the `master` branch is supported). ???TODO: Does GitLab now support `main`???
 
 To host your preset config on GitLab:
 
@@ -151,7 +151,7 @@ To host your preset config on GitLab:
 ## Gitea-hosted Presets
 
 It is also possible to host your preset config using just a regular Gitea repository and without needing to publish it to npmjs.
-In such cases Renovate will simply look for a `renovate.json` file in the default branch, (for now only the _master_ branch is supported).
+In such cases Renovate will simply look for a `renovate.json` file in the default branch, (for now only the `master` branch is supported). ???TODO: Does Gitea support `main` now???
 
 To host your preset config on Gitea:
 

diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md
@@ -178,7 +178,7 @@ This setting is only applicable if you opt in to configure `automerge` to `true`
 
 Automerging defaults to using Pull Requests (`automergeType="pr"`).
 In that case Renovate first creates a branch and associated Pull Request, and then automerges the PR on a subsequent run once it detects the PR's status checks are "green".
-If by the next run the PR is already behind master branch then it will be automatically rebased, because Renovate only automerges branches which are up-to-date and green.
+If by the next run the PR is already behind the `main` branch it will be automatically rebased, because Renovate only automerges branches which are up-to-date and green.
 If Renovate is scheduled for hourly runs on the repository but commits are made every 15 minutes to the main branch, then an automerge like this will keep getting deferred with every rebase.
 
 Note: if you have no tests but still want Renovate to automerge, you need to add `"requiredStatusChecks": null` to your configuration.
@@ -206,12 +206,12 @@ Creating a work item in Azure DevOps is beyond the scope of Renovate, but Renova
 
 ## baseBranches
 
-By default, Renovate will detect and process only the repository's default branch, e.g. `master`.
+By default, Renovate will detect and process only the repository's default branch, e.g. `main`.
 For most projects, this is the expected approach.
 However, Renovate also allows users to explicitly configure `baseBranches`, e.g. for use cases such as:
 
 - You wish Renovate to process only a non-default branch, e.g. `dev`: `"baseBranches": ["dev"]`
-- You have multiple release streams you need Renovate to keep up to date, e.g. in branches `master` and `next`: `"baseBranches": ["master", "next"]`
+- You have multiple release streams you need Renovate to keep up to date, e.g. in branches `main` and `next`: `"baseBranches": ["main", "next"]`
 
 It's possible to add this setting into the `renovate.json` file as part of the "Configure Renovate" onboarding PR.
 If so then Renovate will reflect this setting in its description and use package file contents from the custom base branch(es) instead of default.
@@ -1317,7 +1317,7 @@ Use this field to restrict rules to a particular branch. e.g.
 {
   "packageRules": [
     {
-      "matchBaseBranches": ["master"],
+      "matchBaseBranches": ["main"],
       "excludePackagePatterns": ["^eslint"],
       "enabled": false
     }
@@ -2148,7 +2148,7 @@ It is recommended that you leave this setting to `true`, because of the polite w
 For example, let's say in the above example that you decided you wouldn't update to Webpack 3 for a long time and don't want to build/test every time a new 3.x version arrives.
 In that case, simply close the "Update Webpack to version 3.x" PR and it _won't_ be recreated again even if subsequent Webpack 3.x versions are released.
 You can continue with Webpack 2.x for as long as you want and receive any updates/patches that are made for it.
-Then eventually when you do want to update to Webpack 3.x you can make that update to `package.json` yourself and commit it to master once it's tested.
+Then eventually when you do want to update to Webpack 3.x you can make that update to `package.json` yourself and commit it to the main branch once it's tested.
 After that, Renovate will resume providing you updates to 3.x again!
 i.e. if you close a major upgrade PR then it won't come back again, but once you make the major upgrade yourself then Renovate will resume providing you with minor or patch updates.
 
@@ -2238,7 +2238,7 @@ To opt in to letting Renovate update internal package versions normally, set thi
 ## updateNotScheduled
 
 When schedules are in use, it generally means "no updates".
-However there are cases where updates might be desirable - e.g. if you have configured prCreation=not-pending, or you have rebaseStale=true and master branch is updated so you want Renovate PRs to be rebased.
+However there are cases where updates might be desirable - e.g. if you have configured prCreation=not-pending, or you have rebaseStale=true and the main branch is updated so you want Renovate PRs to be rebased.
 
 This defaults to `true`, meaning that Renovate will perform certain "desirable" updates to _existing_ PRs even when outside of schedule.
 If you wish to disable all updates outside of scheduled hours then configure this field to `false`.

diff --git a/docs/usage/configure-renovate.md b/docs/usage/configure-renovate.md
@@ -19,7 +19,7 @@ You can edit your Renovate configuration **within the `renovate/configure` branc
 ## Check for warnings
 
 If you have any Warnings or Errors listed, see if you need or want to make any changes to address them.
-If you do, then make them in your base branch (e.g. `master`) so that Renovate can recreate its Configure Renovate PR from it on its next cycle.
+If you do, then make them in your base branch (e.g. `main`) so that Renovate can recreate its Configure Renovate PR from it on its next cycle.
 
 ## Configuration location
 

diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
@@ -58,11 +58,11 @@ Note: we'll cover lock files later, don't worry.
 
 Let's say that a "faulty" version `1.2.0` of `foobar` is released and it breaks one of your tests.
 
-If you were using default caret SemVer ranges, then your `master` branch is now "broken" because its `package.json` says that any version 1.x above 1.1.0 is acceptable, and npm will choose the latest (`1.2.0`).
+If you were using default caret SemVer ranges, then your `main` branch is now "broken" because its `package.json` says that any version 1.x above 1.1.0 is acceptable, and npm will choose the latest (`1.2.0`).
 You would need to manually check and work out which dependency caused the failure (`foobar` may not have been the only dependency to have "automatically" upgraded since the last time your tests passed) and then you would need to pin the dependency yourself to stop `npm` installing `1.2.0`.
 
 Consider the same situation if instead you were _pinning_ dependency versions.
-Your `master` would not be broken because it's pinned to `foobar@1.1.0` - instead you'd just have a Pull Request for upgrading to `foobar@1.2.0` which would fail.
+Your `main` branch would not be broken because it's pinned to `foobar@1.1.0` - instead you'd just have a Pull Request for upgrading to `foobar@1.2.0` which would fail.
 You'd know not to merge it and can wait for `foobar@1.2.1` or later when it's fixed.
 Therefore you know exactly what you're running and you know exactly what failed - you have great "visibility".
 
@@ -77,7 +77,7 @@ So first of all, you can choose to read the release notes and/or visually inspec
 
 If you did not catch the fault before merging, you are still better off with a pinned version.
 If you discover something wrong in production, you can easily "roll back" commits in your development environment until you find which rollback fixes the problem.
-Then you can simply revert that commit (reversing `foobar@1.1.0` -> `foobar@1.2.0`) and push that to `master`.
+Then you can simply revert that commit (reversing `foobar@1.1.0` -> `foobar@1.2.0`) and push that to `main`.
 When the next release of `foobar` comes out (e.g. `1.2.1`) you will be prompted with a new PR and hopefully inspect it carefully this time before merge!
 
 As you can see in the above, pinning dependencies makes your build more consistent and predictable as a developer.
@@ -111,10 +111,10 @@ In that case, you could set `automergeType` to `branch`, which means Renovate wi
 
 - Create a new branch for testing
 - Wait until after tests have completed
-- Push the commit directly to `master` if tests pass, or
+- Push the commit directly to `main` if tests pass, or
 - Raise a PR only if tests failed
 
-With this approach, updates will be essentially "silent" - causing no notifications - but you will be able to see each commit on `master` of course.
+With this approach, updates will be essentially "silent" - causing no notifications - but you will be able to see each commit on `main` of course.
 
 ### Scheduling
 

diff --git a/docs/usage/faq.md b/docs/usage/faq.md
@@ -18,14 +18,27 @@ Renovate will:
 - Update `yarn.lock` and/or `package-lock.json` files if found
 - Create Pull Requests immediately after branch creation
 
+## What is this `main` branch I see in the documentation?
+
+When you create a new repository with Git, Git creates a default branch for you.
+The default branch name that Git uses is `master` (this will be changed to `main` later).
+
+The Git-hosting ecosystem has settled on using `main` as the replacement for `master`.
+When you create a new repository on say GitHub or GitLab, you'll get a `main` branch as your default branch.
+
+It therefore makes sense for Renovate to replace `master` with `main` where possible as well.
+
+A branch name has no special meaning within the Git program, it's just a name.
+The default branch could be called `trunk` or `mainline` or `prod`, and Git would work just as well.
+
 ## What if I need to .. ?
 
 ### Use an alternative branch as my Pull Request target
 
-Say your repository's default branch is `master` but you want Renovate to use the `next` branch as its PR target.
+Say your repository's default branch is `main` but you want Renovate to use the `next` branch as its PR target.
 You can configure the PR target branch via the `baseBranches` option.
 
-Add this line to the `renovate.json` file that's in the _default_ branch (`master` in this example).
+Add this line to the `renovate.json` file that's in the _default_ branch (`main` in this example).
 
 ```json
 {

diff --git a/docs/usage/noise-reduction.md b/docs/usage/noise-reduction.md
@@ -12,7 +12,7 @@ This document will give you some ideas of how to reduce the amount of "noise" in
 
 Of course, please keep in mind that people's definitions of "noise" may differ.
 For some people, it's noisy only if they get a notification or email from GitHub.
-For others, too many commits in their `master` branch may be "noise".
+For others, too many commits in their `main` branch may be "noise".
 In other words, your mileage may vary.
 If you have any ideas on this topic, please contact the author by starting a [new discussion on the Renovate repository](https://github.com/renovatebot/renovate/discussions).
 
@@ -62,9 +62,9 @@ There are multiple reasons why Renovate may need to "recreate" PRs after you mer
 
 1. Conflict with `package.json` (sometimes)
 1. Conflict with lock files (often)
-1. If you have configured Renovate or GitHub that PRs must always be kept up-to-date with master
+1. If you have configured Renovate or GitHub that PRs must always be kept up-to-date with `main`
 
-Any of the above reasons can lead to a Renovate branch being considered "stale" and then Renovate needs to rebase it off `master` before you can test and merge again, and Renovate won't do this until it's back in schedule.
+Any of the above reasons can lead to a Renovate branch being considered "stale" and then Renovate needs to rebase it off `main` before you can test and merge again, and Renovate won't do this until it's back in schedule.
 
 ### Selective scheduling
 
@@ -122,18 +122,18 @@ Those of you familiar with GitHub might note that even if you automerge PRs, you
 For this reason we recommend you consider setting `automergeType=branch` which will mean:
 
 - Renovate first creates a branch and no PR
-- If tests pass, Renovate pushes a commit directly to `master` without PR
+- If tests pass, Renovate pushes a commit directly to `main` without PR
 - If tests fail, Renovate raises a PR for you to review
 
-The result is that passing updates are essentially "silent" - the only sign of them are the commits to your `master` branch.
+The result is that passing updates are essentially "silent" - the only sign of them are the commits to your `main` branch.
 
 ### Automerging and scheduling
 
 Automerging is particularly beneficial if you have configured a schedule, because Renovate on its own may be able to automerge the majority of your updates.
 And this is especially so if your repository needs rebasing, e.g. because you use lock files. e.g. let's say you have dependencies `abc` and `xyz` with upgrades, and you use a `yarn.lock` file.
 
 - At the start of the schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates
-- After `abc` passes tests, `Renovate` will automerge it to `master`
+- After `abc` passes tests, `Renovate` will automerge it to `main`
 - The `xyz` branch probably now has `yarn.lock` conflicts
 - Renovate will immediately check all other branches and rebase them
 - The change to `xyz` branch will trigger another round of CI tests
@@ -161,7 +161,7 @@ How about a PR back to [renovate-config](https://github.com/singapore/renovate-c
 
 ## Lock file considerations
 
-Using lock files greatly increases the chance that merging one PR will result in a second PR becoming conflicted with `master`.
+Using lock files greatly increases the chance that merging one PR will result in a second PR becoming conflicted with `main`.
 The table below highlights different noise reduction strategies and their effect on pull request and potential lock file conflicts:
 
 | Action                               | Effect on pull requests  | Chance of lock file conflicts |

diff --git a/docs/usage/self-hosting.md b/docs/usage/self-hosting.md
@@ -179,7 +179,7 @@ workflows:
             filters:
               branches:
                 only:
-                  - master
+                  - main (TODO/QUESTION: Does CircleCI support `main`???)
 ```
 
 ### GitLab CI/CD pipeline

diff --git a/docs/usage/setup-azure-devops.md b/docs/usage/setup-azure-devops.md
@@ -24,7 +24,7 @@ schedules:
   - cron: '0 3 * * *'
     displayName: 'Every day at 3am'
     branches:
-      include: [master]
+      include: [main]
 
 trigger: none
 

diff --git a/lib/manager/azure-pipelines/readme.md b/lib/manager/azure-pipelines/readme.md
@@ -5,7 +5,7 @@ resources:
   repositories:
     - type: github
       name: renovate/renovate
-      ref: refs/heads/master
+      ref: refs/heads/main
     - type: github
       name: user/repo
       ref: refs/tags/v0.5.1