doc: update main branch name in doc/contributing/*

doc/contributing/backporting-to-release-lines.md

@@ -10,7 +10,7 @@ For the active staging branches see the [Release Schedule][].
 
 ## What needs to be backported?
 
-If a cherry-pick from master does not land cleanly on a staging branch, the
+If a cherry-pick from `main` does not land cleanly on a staging branch, the
 releaser will mark the pull request with a particular label for that release
 line (e.g. `backport-requested-vN.x`), specifying to our tooling that this
 pull request should not be included. The releaser will then add a comment

doc/contributing/collaborator-guide.md

@@ -287,11 +287,11 @@ in the form:
 
 * `GIT_REMOTE_REF`: Change to the remote portion of git refspec.
   To specify the branch this way, `refs/heads/BRANCH` is used
-  (e.g. for `master` -> `refs/heads/master`).
+  (e.g. for `main` -> `refs/heads/main`).
   For pull requests, it will look like `refs/pull/PR_NUMBER/head`
   (e.g. for pull request #42 -> `refs/pull/42/head`).
-* `REBASE_ONTO`: Change that to `origin/master` so the pull request gets rebased
-  onto master. This can especially be important for pull requests that have been
+* `REBASE_ONTO`: Change that to `origin/main` so the pull request gets rebased
+  onto `main`. This can especially be important for pull requests that have been
   open a while.
 
 Look at the list of jobs on the left hand side under "Build History" and copy
@@ -337,7 +337,7 @@ For undocumented APIs that are public, open a pull request documenting the API.
 ### Breaking changes
 
 At least two TSC members must approve backward-incompatible changes to the
-master branch.
+`main` branch.
 
 Examples of breaking changes include:
 
@@ -373,7 +373,7 @@ providing a Public API in such cases.
 #### Unintended breaking changes
 
 Sometimes, a change intended to be non-breaking turns out to be a breaking
-change. If such a change lands on the master branch, a collaborator can revert
+change. If such a change lands on the `main` branch, a collaborator can revert
 it. As an alternative to reverting, the TSC can apply the semver-major label
 after-the-fact.
 
@@ -462,7 +462,7 @@ duration.
 
 Communicate pending deprecations and associated mitigations with the ecosystem
 as soon as possible. If possible, do it before the pull request adding the
-deprecation lands on the master branch.
+deprecation lands on the `main` branch.
 
 Use the `notable-change` label on pull requests that add or change the
 deprecation level of an API.
@@ -554,15 +554,15 @@ $ git rebase --abort
 Checkout proper target branch:
 
 ```text
-$ git checkout master
+$ git checkout main
 ```
 
 Update the tree (assumes your repository is set up as detailed in
 [CONTRIBUTING.md](./pull-requests.md#step-1-fork)):
 
 ```text
 $ git fetch upstream
-$ git merge --ff-only upstream/master
+$ git merge --ff-only upstream/main
 ```
 
 Apply external patches:
@@ -588,19 +588,19 @@ has landed since the CI run. You will have to ask the author to rebase.
 Check and re-review the changes:
 
 ```text
-$ git diff upstream/master
+$ git diff upstream/main
 ```
 
 Check the number of commits and commit messages:
 
 ```text
-$ git log upstream/master...master
+$ git log upstream/main...main
 ```
 
 Squash commits and add metadata:
 
 ```text
-$ git rebase -i upstream/master
+$ git rebase -i upstream/main
 ```
 
 This will open a screen like this (in the default shell editor):
@@ -670,19 +670,19 @@ for that commit. This is an opportunity to fix commit messages.
       pull request.
     * Protects against the assumption that GitHub will be around forever.
 
-Other changes might have landed on master since the successful CI run. As a
+Other changes might have landed on `main` since the successful CI run. As a
 precaution, run tests (`make -j4 test` or `vcbuild test`).
 
 Confirm that the commit message format is correct using
 [core-validate-commit](https://github.com/nodejs/core-validate-commit).
 
 ```text
-$ git rev-list upstream/master...HEAD | xargs core-validate-commit
+$ git rev-list upstream/main...HEAD | xargs core-validate-commit
 ```
 
 Optional: For your own commits, force push the amended commit to the pull
 request branch. If your branch name is `bugfix`, then:
-`git push --force-with-lease origin master:bugfix`. Don't close the pull
+`git push --force-with-lease origin main:bugfix`. Don't close the pull
 request. It will close after you push it upstream. It will have the purple
 merged status rather than the red closed status. If you close the pull request
 before GitHub adjusts its status, it will show up as a 0 commit pull
@@ -693,7 +693,7 @@ the issue with the red closed status.
 Time to push it:
 
 ```text
-$ git push upstream master
+$ git push upstream main
 ```
 
 Close the pull request with a "Landed in `<commit hash>`" comment. Even if
@@ -705,27 +705,27 @@ more than one commit.
 
 ### Troubleshooting
 
-Sometimes, when running `git push upstream master`, you might get an error
+Sometimes, when running `git push upstream main`, you might get an error
 message like this:
 
 ```console
 To https://github.com/nodejs/node
- ! [rejected]              master -> master (fetch first)
+ ! [rejected]              main -> main (fetch first)
 error: failed to push some refs to 'https://github.com/nodejs/node'
 hint: Updates were rejected because the tip of your current branch is behind
 hint: its remote counterpart. Integrate the remote changes (e.g.
 hint: 'git pull ...') before pushing again.
 hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 ```
 
-That means a commit has landed since your last rebase against `upstream/master`.
+That means a commit has landed since your last rebase against `upstream/main`.
 To fix this, pull with rebase from upstream, run the tests again, and (if the
 tests pass) push again:
 
 ```bash
-git pull upstream master --rebase
+git pull upstream main --rebase
 make -j4 test
-git push upstream master
+git push upstream main
 ```
 
 ### I made a mistake
@@ -755,7 +755,7 @@ the branch.
 Each LTS release has a corresponding branch (v10.x, v8.x, etc.). Each also has a
 corresponding staging branch (v10.x-staging, v8.x-staging, etc.).
 
-Commits that land on master are cherry-picked to each staging branch as
+Commits that land on `main` are cherry-picked to each staging branch as
 appropriate. If a change applies only to the LTS branch, open the pull request
 against the _staging_ branch. Commits from the staging branch land on the LTS
 branch only when a release is being prepared. They might land on the LTS branch
@@ -901,7 +901,7 @@ We use labels to keep track of which branches a commit should land on:
   * (for example semver-minor changes that need or should go into an LTS
     release)
 * `v?.x`
-  * Automatically applied to changes that do not target `master` but rather the
+  * Automatically applied to changes that do not target `main` but rather the
     `v?.x-staging` branch
 
 Once a release line enters maintenance mode, the corresponding labels do not

doc/contributing/commit-queue.md

@@ -8,7 +8,7 @@ Commit Queue is an experimental feature for the project which simplifies the
 landing process by automating it via GitHub Actions. With it, collaborators can
 land pull requests by adding the `commit-queue` label to a PR. All
 checks will run via node-core-utils, and if the pull request is ready to land,
-the Action will rebase it and push to master.
+the Action will rebase it and push to `main`.
 
 This document gives an overview of how the Commit Queue works, as well as
 implementation details, reasoning for design choices, and current limitations.
@@ -108,7 +108,7 @@ forwarding stdout and stderr to a file. If any errors happen,
 to the PR, as well as a comment with the output of `git node land`.
 
 If no errors happen during `git node land`, the script will use the
-`GITHUB_TOKEN` to push the changes to `master`, and then will leave a
+`GITHUB_TOKEN` to push the changes to `main`, and then will leave a
 `Landed in ...` comment in the PR, and then will close it. Iteration continues
 until all PRs have done the steps above.
 

doc/contributing/diagnostic-tooling-support-tiers.md

@@ -14,7 +14,7 @@ the following tiers.
   suite for the tool/API is not green. To be considered for inclusion
   in this tier it must have a good test suite and that test suite and a job
   must exist in the Node.js CI so that it can be run as part of the release
-  process.  Tests on master will be run nightly when possible to provide
+  process. Tests on `main` will be run nightly when possible to provide
   early warning of potential issues.  No commit to the current and LTS
   release branches should break this tool/API if the next major release
   is within 1 month. In addition:

doc/contributing/maintaining-V8.md

@@ -326,12 +326,12 @@ The rough outline of the process is:
 
 ```bash
 # Assuming your fork of Node.js is checked out in $NODE_DIR
-# and you want to update the Node.js master branch.
+# and you want to update the Node.js main branch.
 # Find the current (OLD) version in
 # $NODE_DIR/deps/v8/include/v8-version.h
 cd $NODE_DIR
-git checkout master
-git merge --ff-only origin/master
+git checkout main
+git merge --ff-only origin/main
 git checkout -b V8_NEW_VERSION
 curl -L https://github.com/v8/v8/compare/${V8_OLD_VERSION}...${V8_NEW_VERSION}.patch | git apply --directory=deps/v8
 # You may want to amend the commit message to describe the nature of the update
@@ -345,13 +345,13 @@ to apply a minor update.
 
 ### Major updates
 
-We upgrade the version of V8 in Node.js master whenever a V8 release goes stable
+We upgrade the version of V8 in Node.js `main` whenever a V8 release goes stable
 upstream, that is, whenever a new release of Chrome comes out.
 
 Upgrading major versions would be much harder to do with the patch mechanism
 above. A better strategy is to
 
-1. Audit the current master branch and look at the patches that have been
+1. Audit the current `main` branch and look at the patches that have been
    floated since the last major V8 update.
 2. Replace the copy of V8 in Node.js with a fresh checkout of the latest stable
    V8 branch. Special care must be taken to recursively update the DEPS that V8
@@ -394,7 +394,7 @@ branches. This has several benefits:
 * The history of the V8 branch in `nodejs/v8` becomes purer and it would make it
   easier to pull in the V8 team for help with reviewing.
 * It would make it simpler to setup an automated build that tracks Node.js
-  master + V8 lkgr integration build.
+  `main` + V8 lkgr integration build.
 
 This would require some tooling to:
 

doc/contributing/maintaining-cjs-module-lexer.md

@@ -17,7 +17,7 @@ implementation using WebAssembly which is generated from a
 C based implementation. These two paths
 resolve to the files in `deps/cjs-module-lexer` due to their
 inclusion in the `deps_files` entry in
-[node.gyp](https://github.com/nodejs/node/blob/master/node.gyp).
+[node.gyp](https://github.com/nodejs/node/blob/main/node.gyp).
 
 The two different versions of lexer.js are maintained in the
 [nodejs/cjs-module-lexer][] project.

doc/contributing/maintaining-npm.md

@@ -41,7 +41,7 @@ Note: please ensure you are only making the updates that are changed by npm.
 ## Step 4: Apply whitespace fix
 
 ```console
-$ git rebase --whitespace=fix master
+$ git rebase --whitespace=fix main
 ```
 
 ## Step 5: Test the build

doc/contributing/maintaining-openssl.md

@@ -5,7 +5,7 @@ This document describes how to update `deps/openssl/`.
 If you need to provide updates across all active release lines you will
 currently need to generate four PRs as follows:
 
-* a PR for master which is generated following the instructions
+* a PR for `main` which is generated following the instructions
   below for OpenSSL 3.x.x.
 * a PR for 16.x following the instructions in the v16.x-staging version
   of this guide.

doc/contributing/maintaining-web-assembly.md

@@ -2,7 +2,7 @@
 
 Support for [WebAssembly](https://webassembly.org/)
 has been identified as one of the
-[top technical priorities](https://github.com/nodejs/node/blob/master/doc/contributing/technical-priorities.md#webassembly)
+[top technical priorities](https://github.com/nodejs/node/blob/main/doc/contributing/technical-priorities.md#webassembly)
 for the future success of Node.js.
 
 This document provides an overview of our high-level strategy for
@@ -76,7 +76,7 @@ The Node.js WASI implementation is maintained in the
 [uvwasi](https://github.com/nodejs/uvwasi) repository in the
 Node.js GitHub organization. As needed, an updated copy
 is vendored into the Node.js deps in
-[deps/uvwasi](https://github.com/nodejs/node/tree/master/deps/uvwasi).
+[deps/uvwasi](https://github.com/nodejs/node/tree/main/deps/uvwasi).
 
 To update the copy of uvwasi in the Node.js deps:
 
@@ -92,6 +92,6 @@ The documentation for this API is in
 
 The implementation of the bindings and the public API is in:
 
-* [src/node\_wasi.h](https://github.com/nodejs/node/blob/master/src/node_wasi.h)
-* [src/node\_wasi.cc](https://github.com/nodejs/node/blob/master/src/node_wasi.cc)
-* [lib/wasi.js](https://github.com/nodejs/node/blob/master/lib/wasi.js)
+* [src/node\_wasi.h](https://github.com/nodejs/node/blob/main/src/node_wasi.h)
+* [src/node\_wasi.cc](https://github.com/nodejs/node/blob/main/src/node_wasi.cc)
+* [lib/wasi.js](https://github.com/nodejs/node/blob/main/lib/wasi.js)

doc/contributing/writing-and-running-benchmarks.md

@@ -256,17 +256,17 @@ As an example on how to check for a possible performance improvement, the
 an example. This pull request _claims_ to improve the performance of the
 `node:string_decoder` module.
 
-First build two versions of Node.js, one from the master branch (here called
-`./node-master`) and another with the pull request applied (here called
+First build two versions of Node.js, one from the `main` branch (here called
+`./node-main`) and another with the pull request applied (here called
 `./node-pr-5134`).
 
 To run multiple compiled versions in parallel you need to copy the output of the
-build: `cp ./out/Release/node ./node-master`. Check out the following example:
+build: `cp ./out/Release/node ./node-main`. Check out the following example:
 
 ```console
-$ git checkout master
+$ git checkout main
 $ ./configure && make -j4
-$ cp ./out/Release/node ./node-master
+$ cp ./out/Release/node ./node-main
 
 $ git checkout pr-5134
 $ ./configure && make -j4
@@ -276,7 +276,7 @@ $ cp ./out/Release/node ./node-pr-5134
 The `compare.js` tool will then produce a csv file with the benchmark results.
 
 ```console
-$ node benchmark/compare.js --old ./node-master --new ./node-pr-5134 string_decoder > compare-pr-5134.csv
+$ node benchmark/compare.js --old ./node-main --new ./node-pr-5134 string_decoder > compare-pr-5134.csv
 ```
 
 _Tips: there are some useful options of `benchmark/compare.js`. For example,

doc/contributing/writing-tests.md

@@ -469,7 +469,7 @@ will depend on what is being tested if this is required or not.
 To generate a test coverage report, see the
 [Test Coverage section of the Building guide][].
 
-Nightly coverage reports for the Node.js master branch are available at
+Nightly coverage reports for the Node.js `main` branch are available at
 <https://coverage.nodejs.org/>.
 
 [ASCII]: https://man7.org/linux/man-pages/man7/ascii.7.html