docs: master branch -> main branch, default branch -> base branch

.github/contributing.md

@@ -34,7 +34,7 @@ Commit as many times as you need in your pull request branch.
 Force pushing a PR is OK when:
 
 - you need to make large changes on a PR which require a full review anyway
-- you need to bring the branch up-to-date with the default branch and incorporating the changes is more work than to create a new PR
+- you need to bring the branch up-to-date with the base branch and incorporating the changes is more work than to create a new PR
 
 ## Re-requesting a review
 

docs/development/design-decisions.md

@@ -43,7 +43,7 @@ By default, `renovate` will maintain separate branches for each dependency.
 So if 20 dependencies need updating, there will be at least 20 branches/PRs.
 Although this may seem undesirable, it's even less desirable if all 20 were in the same Pull Request and it's very difficult to work out which upgrade caused the test failure.
 
-However, you can override the default branch and PR name templates to get a single branch for all dependencies.
+However, you can override the base branch and PR name templates to get a single branch for all dependencies.
 The `groupName` configuration option can be used at a repository level (e.g. give it the value `All`) and then all dependency updates will be in the same branch/PR.
 
 ## Separate Minor and Major PRs

docs/development/shareable-configs.md

@@ -46,7 +46,7 @@ If you use a non-scoped config, you must use a preset name!
 
 ### Git based
 
-In general, GitHub, GitLab or Gitea-based preset hosting is easier than npm because you avoid the "publish" step - simply commit preset code to the default branch and it will be picked up by Renovate the next time it runs.
+In general, GitHub, GitLab or Gitea-based preset hosting is easier than npm because you avoid the "publish" step - simply commit preset code to the base branch and it will be picked up by Renovate the next time it runs.
 An additional benefit of using source code hosting is that the same token/authentication can be reused by Renovate in case you want to make your config private.
 
 | name                    | example use          | preset    | resolves as                          | filename                          |

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 into the base branch
 - 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 base 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

docs/usage/config-presets.md

@@ -30,7 +30,7 @@ In order to achieve these goals, preset configs allow for a very modular approac
 
 ## Preset Hosting
 
-In general, GitHub, GitLab or Gitea-based preset hosting is easier than npm because you avoid the "publish" step - simply commit preset code to the default branch and it will be picked up by Renovate the next time it runs.
+In general, GitHub, GitLab or Gitea-based preset hosting is easier than npm because you avoid the "publish" step - simply commit preset code to the base branch and it will be picked up by Renovate the next time it runs.
 An additional benefit of using source code hosting is that the same token/authentication can be reused by Renovate in case you want to make your config private.
 
 | name                    | example use                | preset    | resolves as                          | filename                          |
@@ -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 base branch, e.g. `main`.
 
 To host your preset config on GitHub:
 
@@ -134,13 +134,13 @@ To host your preset config on GitHub:
   "extends": ["github>rarkins/renovate-config"]
 ```
 
-From then on Renovate will use the Renovate config from the preset repo's default branch.
+From then on Renovate will use the Renovate config from the preset repo's base branch.
 You do not need to add it as a devDependency or add any other files to the preset repo.
 
 ## 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 base branch.
 
 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 base branch.
 
 To host your preset config on Gitea:
 

docs/usage/configuration-options.md

@@ -20,7 +20,7 @@ You can store your Renovate configuration file in one of the following locations
 - `.renovaterc`
 - `package.json` _(within a `"renovate"` section)_
 
-Renovate always uses the config from the repository's default branch, even if that configuration specifies multiple `baseBranches`.
+Renovate always uses the config from the repository's base branch, even if that configuration specifies multiple `baseBranches`.
 Renovate does not read/override the config from within each base branch if present.
 
 Also, be sure to check out Renovate's [shareable config presets](./config-presets.md) to save yourself from reinventing any wheels.
@@ -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 base 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 base branch.
 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 wish Renovate to process only a non-base branch, e.g. `dev`: `"baseBranches": ["dev"]`
+- 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.
@@ -608,7 +608,7 @@ Configure this to `false` if you want to disable release notes fetching
 
 ## fileMatch
 
-`fileMatch` is used by Renovate to know which files in a repository to parse and extract, and it is possible to override defaults values to customize for your project's needs.
+`fileMatch` is used by Renovate to know which files in a repository to parse and extract, and it is possible to override the default values to customize for your project's needs.
 
 Sometimes file matches are really simple - for example with Go Modules Renovate looks for any `go.mod` file, and you probably don't need to change that 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
     }
@@ -2025,7 +2025,7 @@ Currently Renovate's default behavior is to only automerge if every status check
 
 Setting this option to `null` means that Renovate will ignore _all_ status checks.
 You can set this if you don't have any status checks but still want Renovate to automerge PRs.
-Beware: configuring Renovate to automerge without any tests can lead to broken builds on your default branch, please think again before enabling this!
+Beware: configuring Renovate to automerge without any tests can lead to broken builds on your base branch, please think again before enabling this!
 
 In future, this might be configurable to allow certain status checks to be ignored/required.
 See [issue 1853 at the Renovate repository](https://github.com/renovatebot/renovate/issues/1853) for more details.
@@ -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 base 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 base 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`.

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
 

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
 

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 base 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` to replace `master`.
+When you create a new repository on say GitHub or GitLab, you'll get a `main` branch as your base 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 base 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 base 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 _base_ branch (`main` in this example).
 
 ```json
 {
@@ -170,7 +183,7 @@ As above, but apply a `groupName`:
 ]
 ```
 
-### Change the default branch name, commit message, PR title or PR description
+### Change the base branch name, commit message, PR title or PR description
 
 You can use the `branchName`, `commitMessage`, `prTitle` or `prBody` configuration options to change the defaults for those settings.