diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 67d5c02799b694a63c490c9cdca727747ee2da36..9801b24fdd097b7c15b6b50cacd9426f375748a3 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -15,14 +15,14 @@ There are two software distributions of GitLab:
 
 GitLab is available under [different subscriptions](https://about.gitlab.com/pricing/).
 
-New versions of GitLab are released from stable branches, and the `master` branch is used for
+New versions of GitLab are released from stable branches, and the `main` branch is used for
 bleeding-edge development.
 
 For more information, visit the [GitLab Release Process](https://about.gitlab.com/handbook/engineering/releases/).
 
 Both distributions require additional components. These components are described in the
 [Component details](#components) section, and all have their own repositories.
-New versions of each dependent component are usually tags, but staying on the `master` branch of the
+New versions of each dependent component are usually tags, but staying on the `main` branch of the
 GitLab codebase gives you the latest stable version of those components. New versions are
 generally released around the same time as GitLab releases, with the exception of informal security
 updates deemed critical.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index b91e27b7051eaf416f9ac6971d7f9410f3298403..df09b27c6b4a70141229e2b9e7fbf3bd0a33fafb 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -418,13 +418,13 @@ WARNING:
 - Start a new merge request pipeline with the `Run pipeline` button in the merge
   request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).
   Note that:
-  - If **[master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
+  - If **[main is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
     do not merge the merge request** except for
     [very specific cases](https://about.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master).
     For other cases, follow these [handbook instructions](https://about.gitlab.com/handbook/engineering/workflow/#merging-during-broken-master).
   - If the **latest [Pipeline for Merged Results](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results)** finished less than 2 hours ago, you
     might merge without starting a new pipeline as the merge request is close
-    enough to `master`.
+    enough to `main`.
 - When you set the MR to "Merge When Pipeline Succeeds", you should take over
   subsequent revisions for anything that would be spotted after that.
 - For merge requests that have had [Squash and
@@ -434,11 +434,11 @@ WARNING:
 
 Thanks to **Pipeline for Merged Results**, authors no longer have to rebase their
 branch as frequently anymore (only when there are conflicts) because the Merge
-Results Pipeline already incorporate the latest changes from `master`.
+Results Pipeline already incorporate the latest changes from `main`.
 This results in faster review/merge cycles because maintainers don't have to ask
 for a final rebase: instead, they only have to start a MR pipeline and set MWPS.
 This step brings us very close to the actual Merge Trains feature by testing the
-Merge Results against the latest `master` at the time of the pipeline creation.
+Merge Results against the latest `main` at the time of the pipeline creation.
 
 ### Community contributions
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 9d34b065e242d0405d7e9ea6b7085cb5c263ddca..840434ebbc350238ab88d3edc9837ec8d6a00d27 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -325,7 +325,7 @@ the [appropriate product manager](https://about.gitlab.com/handbook/product/#who
 as soon as possible. The product manager will then pull in appropriate GitLab team
 members to further discuss scope, design, and technical considerations. This will
 ensure that your contribution is aligned with the GitLab product and minimize
-any rework and delay in getting it merged into master.
+any rework and delay in getting it merged into main.
 
 GitLab team members who apply the ~"Accepting merge requests" label to an issue
 should update the issue description with a responsible product manager, inviting
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index ed4631408f87e629c6dead3365fb7f2e31748ebc..783cf7af6fcd7320da6f7f71299b0fb99d631931 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -44,7 +44,7 @@ request is as follows:
 
 1. [Fork](../../user/project/repository/forking_workflow.md) the project into
    your personal namespace (or group) on GitLab.com.
-1. Create a feature branch in your fork (don't work off `master`).
+1. Create a feature branch in your fork (don't work off your [default branch](../../user/project/repository/branches/default.md)).
 1. Write [tests](../rake_tasks.md#run-tests) and code.
 1. [Ensure a changelog is created](../changelog.md).
 1. If you are writing documentation, make sure to follow the
@@ -54,7 +54,7 @@ request is as follows:
    commits by [squashing them](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing),
    but do not change the commit history if you're working on shared branches though.
 1. Push the commit(s) to your working branch in your fork.
-1. Submit a merge request (MR) to the `master` branch in the main GitLab project.
+1. Submit a merge request (MR) to the `main` branch in the main GitLab project.
    1. Your merge request needs at least 1 approval, but depending on your changes
       you might need additional approvals. Refer to the [Approval guidelines](../code_review.md#approval-guidelines).
    1. You don't have to select any specific approvers, but you can if you really want
@@ -196,12 +196,12 @@ the contribution acceptance criteria below:
    exposing a bug in existing code). Every new class should have corresponding
    unit tests, even if the class is exercised at a higher level, such as a feature test.
    - If a failing CI build seems to be unrelated to your contribution, you can try
-     restarting the failing CI job, rebasing from `master` to bring in updates that
+     restarting the failing CI job, rebasing from `main` to bring in updates that
      may resolve the failure, or if it has not been fixed yet, ask a developer to
      help you fix the test.
 1. The MR initially contains a few logically organized commits.
 1. The changes can merge without problems. If not, you should rebase if you're the
-   only one working on your feature branch, otherwise merge `master`.
+   only one working on your feature branch, otherwise merge `main`.
 1. Only one specific issue is fixed or one specific feature is implemented. Do not
    combine things; send separate merge requests for each issue or feature.
 1. Migrations should do only one thing (e.g., create a table, move data to a new
diff --git a/doc/development/diffs.md b/doc/development/diffs.md
index 52ba89a4d6e7790c5ed270619d3e88b4ac9c90cd..aaa3340af338f7cf326475ad645e49c438f7f5d6 100644
--- a/doc/development/diffs.md
+++ b/doc/development/diffs.md
@@ -156,13 +156,13 @@ Historically, merge request diffs have been calculated by `git diff target...sou
 `HEAD` of the source branch with the merge base (or a common ancestor) of the target branch and the source's.
 This solution works well until the target branch starts containing some of the
 changes introduced by the source branch: Consider the following case, in which the source branch
-is `feature_a` and the target is `master`:
+is `feature_a` and the target is `main`:
 
-1. Checkout a new branch `feature_a` from `master` and remove `file_a` and `file_b` in it.
-1. Add a commit that removes `file_a` to `master`.
+1. Checkout a new branch `feature_a` from `main` and remove `file_a` and `file_b` in it.
+1. Add a commit that removes `file_a` to `main`.
 
 The merge request diff still contains the `file_a` removal while the actual diff compared to
-`master`'s `HEAD` has only the `file_b` removal. The diff with such redundant
+`main`'s `HEAD` has only the `file_b` removal. The diff with such redundant
 changes is harder to review.
 
 In order to display an up-to-date diff, in GitLab 12.9 we
@@ -174,16 +174,16 @@ diff.
 
 Until we complete the epics ["use merge refs for diffs"](https://gitlab.com/groups/gitlab-org/-/epics/854)
 and ["merge conflicts in diffs"](https://gitlab.com/groups/gitlab-org/-/epics/4893),
-both options `master (base)` and `master (HEAD)` are available to be displayed in merge requests:
+both options `main (base)` and `main (HEAD)` are available to be displayed in merge requests:
 
 ![Merge ref head options](img/merge_ref_head_options_v13_6.png)
 
-The `master (HEAD)` option is meant to replace `master (base)` in the future.
+The `main (HEAD)` option is meant to replace `main (base)` in the future.
 
 In order to support comments for both options, diff note positions are stored for
-both `master (base)` and `master (HEAD)` versions ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198457) in 12.10).
-The position for `master (base)` version is stored in `Note#position` and
-`Note#original_position` columns, for `master (HEAD)` version `DiffNotePosition`
+both `main (base)` and `main (HEAD)` versions ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198457) in 12.10).
+The position for `main (base)` version is stored in `Note#position` and
+`Note#original_position` columns, for `main (HEAD)` version `DiffNotePosition`
 has been introduced.
 
 One of the key challenges to deal with when working on merge ref diffs are merge
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index caad0ee6cfecbf7ae6dc70cf7d16ca47b3361ca8..12a1912dd250d1546ff3dc3c711e19527410cdf2 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -317,7 +317,8 @@ it increases the work of the release managers.
 Every GitLab instance includes the documentation, which is available at `/help`
 (`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>.
 
-The documentation available online on <https://docs.gitlab.com> is deployed every four hours from the `master` branch of GitLab, Omnibus, and Runner. Therefore,
+The documentation available online on <https://docs.gitlab.com> is deployed every
+four hours from the `main` branch of GitLab, Omnibus, and Runner. Therefore,
 after a merge request gets merged, it is available online on the same day.
 However, it's shipped (and available on `/help`) within the milestone assigned
 to the MR.
@@ -461,7 +462,7 @@ If you want to know the in-depth details, here's what's really happening:
 1. You manually run the `review-docs-deploy` job in a merge request.
 1. The job runs the [`scripts/trigger-build`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/trigger-build)
    script with the `docs deploy` flag, which triggers the "Triggered from `gitlab-org/gitlab` 'review-docs-deploy' job"
-   pipeline trigger in the `gitlab-org/gitlab-docs` project for the `$DOCS_BRANCH` (defaults to `master`).
+   pipeline trigger in the `gitlab-org/gitlab-docs` project for the `$DOCS_BRANCH` (defaults to `main`).
 1. The preview URL is shown both at the job output and in the merge request
    widget. You also get the link to the remote pipeline.
 1. In the `gitlab-org/gitlab-docs` project, the pipeline is created and it
diff --git a/doc/development/documentation/site_architecture/deployment_process.md b/doc/development/documentation/site_architecture/deployment_process.md
index cded54c7c43455a09f6c28f9c733fef6fb0f2738..1b764ada87b6da696b1f2ba2e28086a99728730d 100644
--- a/doc/development/documentation/site_architecture/deployment_process.md
+++ b/doc/development/documentation/site_architecture/deployment_process.md
@@ -55,10 +55,10 @@ The website keeps changing and being improved. In order to consolidate
 those changes to the stable branches, we'd need to pick certain changes
 from time to time.
 
-If this is not possible or there are many changes, merge master into them:
+If this is not possible or there are many changes, merge main into them:
 
 ```shell
 git branch 12.0
-git fetch origin master
-git merge origin/master
+git fetch origin main
+git merge origin/main
 ```
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 95fe65406eb5963260f9f3c7460c275e2e36541c..d410d77a1a0ab009ce8cddf5d7987a287cf18834 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -114,7 +114,7 @@ located in the [Dockerfiles directory](https://gitlab.com/gitlab-org/gitlab-docs
 If you need to rebuild the Docker images immediately (must have maintainer level permissions):
 
 WARNING:
-If you change the Dockerfile configuration and rebuild the images, you can break the master
+If you change the Dockerfile configuration and rebuild the images, you can break the main
 pipeline in the main `gitlab` repository as well as in `gitlab-docs`. Create an image with
 a different name first and test it to ensure you do not break the pipelines.
 
@@ -132,7 +132,7 @@ a different name first and test it to ensure you do not break the pipelines.
 ### Deploy the docs site
 
 Every four hours a scheduled pipeline builds and deploys the docs site. The pipeline
-fetches the current docs from the main project's master branch, builds it with Nanoc
+fetches the current docs from the main project's main branch, builds it with Nanoc
 and deploys it to <https://docs.gitlab.com>.
 
 If you need to build and deploy the site immediately (must have maintainer level permissions):
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 32a130aeeb8a1487d55c81fe01cc2d4761ea18d0..225db273cb6ca9856a40c69e97e587eef9c9c607 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -1276,7 +1276,7 @@ hidden on the documentation site, but is displayed by `/help`.
 ## Code blocks
 
 - Always wrap code added to a sentence in inline code blocks (`` ` ``).
-  For example, `.gitlab-ci.yml`, `git add .`, `CODEOWNERS`, or `only: [master]`.
+  For example, `.gitlab-ci.yml`, `git add .`, `CODEOWNERS`, or `only: [main]`.
   File names, commands, entries, and anything that refers to code should be
   added to code blocks. To make things easier for the user, always add a full
   code block for things that can be useful to copy and paste, as they can do it
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index 241cedfd944e2b882da938c18ba8424137033802..79a100e44a50401cef351163a4f07c5e273208e8 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -41,7 +41,7 @@ should be leveraged:
 
   1. [Create a new feature flag](#create-a-new-feature-flag)
      which is **off** by default, in the first merge request which uses the flag.
-     Flags [should not be added separately](#risk-of-a-broken-master-main-branch).
+     Flags [should not be added separately](#risk-of-a-broken-main-branch).
   1. Submit incremental changes via one or more merge requests, ensuring that any
      new code added can only be reached if the feature flag is **on**.
      You can keep the feature flag enabled on your local GDK during development.
@@ -59,11 +59,11 @@ flag does not have to stick around for a specific amount of time
 is deemed stable. Stable means it works on GitLab.com without causing any
 problems, such as outages.
 
-## Risk of a broken master (main) branch
+## Risk of a broken main branch
 
-Feature flags **must** be used in the MR that introduces them. Not doing so causes a
-[broken master](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) scenario due
-to the `rspec:feature-flags` job that only runs on the `master` branch.
+Feature flags must be used in the MR that introduces them. Not doing so causes a
+[broken main branch](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) scenario due
+to the `rspec:feature-flags` job that only runs on the `main` branch.
 
 ## Types of feature flags
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index ac568389e51a0c1da9095648e74c73e3f1d80e5c..009ead8ba1624cbcbe0a8a28c2d5ba12cb41a11b 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -45,16 +45,16 @@ columns manually for existing tables as this causes confusion to
 other people using `db/structure.sql` generated by Rails.
 
 When your local database in your GDK is diverging from the schema from
-`master` it might be hard to cleanly commit the schema changes to
+`main` it might be hard to cleanly commit the schema changes to
 Git. In that case you can use the `scripts/regenerate-schema` script to
 regenerate a clean `db/structure.sql` for the migrations you're
 adding. This script applies all migrations found in `db/migrate`
 or `db/post_migrate`, so if there are any migrations you don't want to
 commit to the schema, rename or remove them. If your branch is not
-targeting `master` you can set the `TARGET` environment variable.
+targeting `main` you can set the `TARGET` environment variable.
 
 ```shell
-# Regenerate schema against `master`
+# Regenerate schema against `main`
 scripts/regenerate-schema
 
 # Regenerate schema against `12-9-stable-ee`
diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md
index 8ae503ec7090366173370da93a3bc61e8f41a8dd..f34c407da845aae9b7837463eb4ab0a23b959ccc 100644
--- a/doc/development/new_fe_guide/development/performance.md
+++ b/doc/development/new_fe_guide/development/performance.md
@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
 These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
-Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes are pushed live on the next scheduled run after the changes are merged into `master`.
+Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes are pushed live on the next scheduled run after the changes are merged into `main`.
 
 There are 3 recommended high impact metrics to review on each page:
 
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index c3fb66cb085085cbf7eb168026703903a4d31368..0dc1481f542e60b0df37acaed0e8218efbe2c264 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -24,7 +24,7 @@ feature of the GitLab CI/CD.
 
 Pipelines are always created for the following scenarios:
 
-- `master` branch, including on schedules, pushes, merges, and so on.
+- `main` branch, including on schedules, pushes, merges, and so on.
 - Merge requests.
 - Tags.
 - Stable, `auto-deploy`, and security branches.
@@ -428,7 +428,7 @@ We are using a custom mapping between source file to test files, maintained in t
 
 As part of the objective to improve overall pipeline duration, we are experimenting with a minimal set of RSpec tests.
 The purpose of this experiment is to verify if we are able to run a minimal set of RSpec tests in a Merge Request pipeline,
-without resulting in increased number of broken master.
+without resulting in increased number of broken main branch.
 
 To identify the minimal set of tests needed, we use [Crystalball gem](https://github.com/toptal/crystalball) to create a test mapping.
 The test mapping contains a map of each source files to a list of test files which is dependent of the source file.
@@ -484,14 +484,14 @@ Our test suite runs against PG12 as GitLab.com runs on PG12 and
 Our test suite is currently running against PG11, since GitLab.com still runs on PG11.
 
 We do run our test suite against PG11 on nightly scheduled pipelines as well as upon specific
-database library changes in MRs and `master` pipelines (with the `rspec db-library-code pg11` job).
+database library changes in MRs and `main` pipelines (with the `rspec db-library-code pg11` job).
 
 #### Current versions testing
 
 | Where? | PostgreSQL version |
 | ------ | ------------------ |
 | MRs    | 12, 11 for DB library changes |
-| `master` (non-scheduled pipelines) | 12, 11 for DB library changes |
+| `main` (non-scheduled pipelines) | 12, 11 for DB library changes |
 | 2-hourly scheduled pipelines | 12, 11 for DB library changes |
 | `nightly` scheduled pipelines | 12, 11 |
 
@@ -538,7 +538,7 @@ the `gitlab-org/gitlab-foss` project.
 ### Interruptible pipelines
 
 By default, all jobs are [interruptible](../ci/yaml/README.md#interruptible), except the
-`dont-interrupt-me` job which runs automatically on `master`, and is `manual`
+`dont-interrupt-me` job which runs automatically on `main`, and is `manual`
 otherwise.
 
 If you want a running pipeline to finish even if you push new commits to a merge
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index 3860665024ad665644a40a33116904338c351c0a..8d20c2b738e93d4773d5f8c1ca8564a5af0200c5 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -236,7 +236,7 @@ task, then check the dimensions of the new sprite sheet and update the
 ## Update project templates
 
 Starting a project from a template needs this project to be exported. On a
-up to date master branch run:
+up to date main branch run:
 
 ```shell
 gdk start
@@ -247,7 +247,7 @@ git commit
 git push -u origin update-project-templates
 ```
 
-Now create a merge request and merge that to master.
+Now create a merge request and merge that to main.
 
 ## Generate route lists
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 4ed5bfc7eb56d46f5a2af05a5a6c48863b5fd097..4ca4ea0e64ef062f5b0f9017843a4f075ab47fac 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -1148,7 +1148,7 @@ module Spec
     module Helpers
       module CycleAnalyticsHelpers
         def create_commit_referencing_issue(issue, branch_name: random_git_name)
-          project.repository.add_branch(user, branch_name, 'master')
+          project.repository.add_branch(user, branch_name, 'main')
           create_commit("Commit for ##{issue.iid}", issue.project, user, branch_name)
         end
       end
@@ -1205,7 +1205,7 @@ let(:project) { create(:project, :repository) }
 ```
 
 Where you can, consider using the `:custom_repo` trait instead of `:repository`.
-This allows you to specify exactly what files appear in the `master` branch
+This allows you to specify exactly what files appear in the `main` branch
 of the project's repository. For example:
 
 ```ruby
diff --git a/doc/development/testing_guide/ci.md b/doc/development/testing_guide/ci.md
index 7318f7672192b2e182ec94686e33433de036386c..e3fccdcee34025f6f784b4985e233159c25eb9b3 100644
--- a/doc/development/testing_guide/ci.md
+++ b/doc/development/testing_guide/ci.md
@@ -12,7 +12,7 @@ Our current CI parallelization setup is as follows:
 
 1. The `retrieve-tests-metadata` job in the `prepare` stage ensures we have a
    `knapsack/report-master.json` file:
-   - The `knapsack/report-master.json` file is fetched from the latest `master` pipeline which runs `update-tests-metadata`
+   - The `knapsack/report-master.json` file is fetched from the latest `main` pipeline which runs `update-tests-metadata`
      (for now it's the 2-hourly scheduled master pipeline), if it's not here we initialize the file with `{}`.
 1. Each `[rspec|rspec-ee] [unit|integration|system|geo] n m` job are run with
    `knapsack rspec` and should have an evenly distributed share of tests:
@@ -31,7 +31,7 @@ After that, the next pipeline uses the up-to-date `knapsack/report-master.json`
 
 ## Monitoring
 
-The GitLab test suite is [monitored](../performance.md#rspec-profiling) for the `master` branch, and any branch
+The GitLab test suite is [monitored](../performance.md#rspec-profiling) for the `main` branch, and any branch
 that includes `rspec-profile` in their name.
 
 ## CI setup
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md
index 4f9d68983d263891e1564ef2cca582c7e33e9175..c9acb2e93719f11902f3d2412ab1359c8c505c58 100644
--- a/doc/development/testing_guide/end_to_end/feature_flags.md
+++ b/doc/development/testing_guide/end_to_end/feature_flags.md
@@ -81,7 +81,7 @@ End-to-end tests should pass with a feature flag enabled before it is enabled on
 
 If a test enables a feature flag as describe above, it is sufficient to run the `package-and-qa` job in a merge request containing the relevant changes.
 Or, if the feature flag and relevant changes have already been merged, you can confirm that the tests
-pass on `master`. The end-to-end tests run on `master` every two hours, and the results are posted to a [Test
+pass on `main`. The end-to-end tests run on `main` every two hours, and the results are posted to a [Test
 Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amaster).
 
 If the relevant tests do not enable the feature flag themselves, you can check if the tests will need
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index dd4e04b78aa5af2f4d246f189d3792c3355ab9bf..bfcd68dbaf3a68149238d51b3dddc350318d0dbd 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -13,7 +13,7 @@ eventually.
 
 ## Quarantined tests
 
-When a test frequently fails in `master`,
+When a test frequently fails in `main`,
 [a ~"master:broken" issue](https://about.gitlab.com/handbook/engineering/workflow/#broken-master)
 should be created.
 If the test cannot be fixed in a timely fashion, there is an impact on the
@@ -56,7 +56,7 @@ On our CI, we use [RSpec::Retry](https://github.com/NoRedInk/rspec-retry) to aut
 times (see [`spec/spec_helper.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/spec_helper.rb) for the precise retries count).
 
 We also use a home-made `RspecFlaky::Listener` listener which records flaky
-examples in a JSON report file on `master` (`retrieve-tests-metadata` and
+examples in a JSON report file on `main` (`retrieve-tests-metadata` and
 `update-tests-metadata` jobs).
 
 This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13021>.
diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md
index d31f329f8c3221422fb43aa33ec42d096ac0a32b..d1231257f38635d37ed49df2a5033e765b2658bf 100644
--- a/doc/topics/git/lfs/migrate_to_git_lfs.md
+++ b/doc/topics/git/lfs/migrate_to_git_lfs.md
@@ -137,8 +137,8 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    # Change into the upstream repo directory:
    cd test-git-lfs-repo-migration
 
-   # You may need to reset your local copy with upstream's `master` after force-pushing from the mirror:
-   git reset --hard origin/master
+   # You may need to reset your local copy with upstream's `main` after force-pushing from the mirror:
+   git reset --hard origin/main
 
    # Track the files with LFS:
    git lfs track "*.gif" "*.png" "*.jpg" "*.psd" "*.mp4" "img/"
diff --git a/doc/user/project/merge_requests/versions.md b/doc/user/project/merge_requests/versions.md
index 676af4b288117daf3ca6892c00d4ada927b453ed..1d196de36e253dd2cc97fb6b2d26814c069040da 100644
--- a/doc/user/project/merge_requests/versions.md
+++ b/doc/user/project/merge_requests/versions.md
@@ -64,7 +64,7 @@ In GitLab 12.10, we added a comparison mode, which
 shows a diff calculated by simulating how it would look like once merged - a more accurate
 representation of the changes rather than using the base of the two
 branches. The new mode is available from the comparison target drop down
-by selecting **master (HEAD)**. In GitLab 13.9, it
+by selecting **main (HEAD)**. In GitLab 13.9, it
 [replaced](https://gitlab.com/gitlab-org/gitlab/-/issues/198458) the
 old default comparison. For technical details, additional information is available in the
 [developer documentation](../../../development/diffs.md#merge-request-diffs-against-the-head-of-the-target-branch).