docs: Update Branch Name (#31106)

* docs: Update CI Badge Branch Name

The CI badges were still pointing at builds for the master branch, which
are stale since the rename to main.

* docs: Update electron/electron Branch Name

Update electron/electron branch name from master to main.

* docs: Update electron/governance Branch Name

Update electron/governance branch name from master to main.

docs/development/README.md

@@ -4,8 +4,8 @@ These guides are intended for people working on the Electron project itself.
 For guides on Electron app development, see
 [/docs/README.md](../README.md#guides-and-tutorials).
 
-* [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md)
-* [Contributing to Electron](https://github.com/electron/electron/blob/master/CONTRIBUTING.md)
+* [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md)
+* [Contributing to Electron](https://github.com/electron/electron/blob/main/CONTRIBUTING.md)
 * [Issues](issues.md)
 * [Pull Requests](pull-requests.md)
 * [Documentation Styleguide](coding-style.md#documentation)

docs/development/azure-vm-setup.md

@@ -8,7 +8,7 @@ Example Use Case:
     * We need `VS15.9` and we have `VS15.7` installed; this would require us to update an Azure image.
 
 1. Identify the image you wish to modify.
-    * In [appveyor.yml](https://github.com/electron/electron/blob/master/appveyor.yml), the image is identified by the property *image*.
+    * In [appveyor.yml](https://github.com/electron/electron/blob/main/appveyor.yml), the image is identified by the property *image*.
         * The names used correspond to the *"images"* defined for a build cloud, eg the [libcc-20 cloud](https://windows-ci.electronjs.org/build-clouds/8).
     * Find the image you wish to modify in the build cloud and make note of the **VHD Blob Path** for that image, which is the value for that corresponding key.
         * You will need this URI path to copy into a new image.

docs/development/build-instructions-gn.md

@@ -65,8 +65,8 @@ origin URLs.
 $ cd src/electron
 $ git remote remove origin
 $ git remote add origin https://github.com/electron/electron
-$ git checkout master
-$ git branch --set-upstream-to=origin/master
+$ git checkout main
+$ git branch --set-upstream-to=origin/main
 $ cd -
 ```
 

docs/development/electron-vs-nwjs.md

@@ -72,4 +72,4 @@ to try NW.js.
 
 [nwjs]: https://nwjs.io/
 [electron-modules]: https://www.npmjs.com/search?q=electron
-[node-bindings]: https://github.com/electron/electron/tree/master/lib/common
+[node-bindings]: https://github.com/electron/electron/tree/main/lib/common

docs/development/pull-requests.md

@@ -45,10 +45,10 @@ Once you've built the project locally, you're ready to start making changes!
 ### Step 3: Branch
 
 To keep your development environment organized, create local branches to
-hold your work. These should be branched directly off of the `master` branch.
+hold your work. These should be branched directly off of the `main` branch.
 
 ```sh
-$ git checkout -b my-branch -t upstream/master
+$ git checkout -b my-branch -t upstream/main
 ```
 
 ## Making Changes
@@ -134,11 +134,11 @@ Once you have committed your changes, it is a good idea to use `git rebase`
 
 ```sh
 $ git fetch upstream
-$ git rebase upstream/master
+$ git rebase upstream/main
 ```
 
 This ensures that your working branch has the latest changes from `electron/electron`
-master.
+main.
 
 ### Step 7: Test
 
@@ -189,7 +189,7 @@ the requirements below.
 
 Bug fixes and new features should include tests and possibly benchmarks.
 
-Contributors guide: https://github.com/electron/electron/blob/master/CONTRIBUTING.md
+Contributors guide: https://github.com/electron/electron/blob/main/CONTRIBUTING.md
 -->
 ```
 
@@ -222,7 +222,7 @@ seem unfamiliar, refer to this
 #### Approval and Request Changes Workflow
 
 All pull requests require approval from a
-[Code Owner](https://github.com/electron/electron/blob/master/.github/CODEOWNERS)
+[Code Owner](https://github.com/electron/electron/blob/main/.github/CODEOWNERS)
 of the area you modified in order to land. Whenever a maintainer reviews a pull
 request they may request changes. These may be small, such as fixing a typo, or
 may involve substantive changes. Such requests are intended to be helpful, but