Remove 'master' mentions from Source Code pages

These pages all mentioned 'master' and needed to be updated to point
to either the documentation for default branches, or to use 'main'
instead.

doc/gitlab-basics/create-branch.md

@@ -11,7 +11,7 @@ A branch is an independent line of development in a [project](../user/project/in
 
 When you create a new branch (in your [terminal](start-using-git.md#create-a-branch) or with
 [the web interface](../user/project/repository/web_editor.md#create-a-new-branch)),
-you are creating a snapshot of a certain branch, usually the main `master` branch,
+you are creating a snapshot of a certain branch, usually the main branch,
 at its current state. From there, you can start to make your own changes without
 affecting the main codebase. The history of your changes is tracked in your branch.
 

doc/gitlab-basics/start-using-git.md

@@ -295,8 +295,9 @@ After you've done that, you can [stage your files](#add-and-commit-local-changes
 
 To work on an up-to-date copy of the project (it is important to do this every time
 you start working on a project), you `pull` to get all the changes made by users
-since the last time you cloned or pulled the project. Use `master` for the
-`<name-of-branch>` to get the main branch code, or the branch name of the branch
+since the last time you cloned or pulled the project. Replace `<name-of-branch>`
+with the name of your [default branch](../user/project/repository/branches/default.md)
+to get the main branch code, or replace it with the branch name of the branch
 you are currently working in.
 
 ```shell
@@ -305,7 +306,8 @@ git pull <REMOTE> <name-of-branch>
 
 When you clone a repository, `REMOTE` is typically `origin`. This is where the
 repository was cloned from, and it indicates the SSH or HTTPS URL of the repository
-on the remote server. `<name-of-branch>` is usually `master`, but it may be any
+on the remote server. `<name-of-branch>` is usually the name of your
+[default branch](../user/project/repository/branches/default.md), but it may be any
 existing branch. You can create additional named remotes and branches as necessary.
 
 You can learn more on how Git manages remote repositories in the
@@ -330,14 +332,14 @@ to work on a different **branch**.
 When you create a branch in a Git repository, you make a copy of its files at the time of branching. You're free
 to do whatever you want with the code in your branch without impacting the main branch or other branches. And when
 you're ready to bring your changes to the main codebase, you can merge your branch into the default branch
-used in your project (such as `master`).
+used in your project (such as `main`).
 
 A new branch is often called **feature branch** to differentiate from the
-**default branch**.
+[default branch](../user/project/repository/branches/default.md).
 
 ### Create a branch
 
-To create a new feature branch and work from without affecting the `master`
+To create a new feature branch and work from without affecting the default
 branch:
 
 ```shell
@@ -348,14 +350,15 @@ Note that Git does **not** accept empty spaces and special characters in branch
 names, so use only lowercase letters, numbers, hyphens (`-`), and underscores
 (`_`). Do not use capital letters, as it may cause duplications.
 
-### Switch to the master branch
+### Switch to the default branch
 
-You are always in a branch when working with Git. The main branch is the master
-branch, but you can use the same command to switch to a different branch by
-changing `master` to the branch name.
+You are always in a branch when working with Git. The
+[default branch](../user/project/repository/branches/default.md) can vary depending
+on your version of GitLab, but you can alter this command to switch to a different branch by
+changing `main` to the branch name:
 
 ```shell
-git checkout master
+git checkout main
 ```
 
 ### Work on an existing branch
@@ -417,10 +420,10 @@ To push all local commits (saved changes) to the remote repository:
 git push <remote> <name-of-branch>
 ```
 
-For example, to push your local commits to the _`master`_ branch of the _`origin`_ remote:
+For example, to push your local commits to the _`main`_ branch of the _`origin`_ remote:
 
 ```shell
-git push origin master
+git push origin main
 ```
 
 On certain occasions, Git disallows pushes to your repository, and then
@@ -464,14 +467,15 @@ A Git commit should not usually be reversed, particularly if you already pushed
 to the remote repository. Although you can undo a commit, the best option is to avoid
 the situation altogether by working carefully.
 
-### Merge a branch with master branch
+### Merge a branch with default branch
 
 When you are ready to make all the changes in a branch a permanent addition to
-the master branch, you `merge` the two together:
+the default branch, you `merge` the two together, changing `<feature-branch>` and
+`<default-branch>` to your values:
 
 ```shell
-git checkout <name-of-branch>
-git merge master
+git checkout <feature-branch>
+git merge <default-branch>
 ```
 
 ## Advanced use of Git through the command line

doc/topics/git/feature_branch_development.md

@@ -9,7 +9,7 @@ type: how-tos
 
 GitLab values encourage the use of [Minimal Viable Change (MVC)](https://about.gitlab.com/handbook/values/#minimal-viable-change-mvc).
 However, viable changes are not always small. In such cases, it can help to set up a dedicated feature branch.
-People can contribute MRs to that feature branch, without affecting the functionality of the default (usually `master`) branch.
+People can contribute MRs to that feature branch, without affecting the functionality of the [default branch](../../user/project/repository/branches/default.md).
 
 Once work on the development branch is complete, then the feature branch can be finally merged into the default branch.
 
@@ -19,14 +19,14 @@ GitLab frequently implements this process whenever there is an MVC that requires
 
 This section describes the use case with GitLab [release posts](https://about.gitlab.com/handbook/marketing/blog/release-posts/).
 Dozens of GitLab team members contribute to each monthly release post.
-In such cases, it may be more efficient to submit an MR on the release post feature branch instead of master.
+In such cases, it may be more efficient to submit an MR on the release post feature branch instead of the [default branch](../../user/project/repository/branches/default.md).
 
 In this case, the feature branch would be `release-X-Y`. Assuming the `release-X-Y` branch already exists, you can set up an MR against that branch, with the following steps:
 
-1. Navigate to the main (master) branch:
+1. Navigate to the [default branch](../../user/project/repository/branches/default.md) (here, `main`):
 
    ```shell
-   git checkout master
+   git checkout main
    ```
 
 1. Make sure you have the latest version of your repository:
@@ -101,8 +101,8 @@ we have selected `test-branch` as the source, and `release-13-0` as the target.
    Request to merge test-branch into release-13-0
    ```
 
-   That confirms you've set up the MR to merge into the specified branch, not master.
+   That confirms you've set up the MR to merge into the specified branch, not the [default branch](../../user/project/repository/branches/default.md).
 
 1. Proceed with the change as you would with any other MR.
 1. When your MR is approved, and an appropriate user merges that MR, you can rest assured that your work is incorporated directly into the feature branch.
-When the feature branch is ready, it can then be merged into master.
+When the feature branch is ready, it can then be merged into the [default branch](../../user/project/repository/branches/default.md).

doc/topics/git/git_rebase.md

@@ -80,12 +80,13 @@ ensure that the changes you're adding to the codebase do not break any
 existing changes added to the target branch _after_ you created your feature
 branch.
 
-For example, to update your branch `my-feature-branch` with `master`:
+For example, to update your branch `my-feature-branch` with your
+[default branch](../../user/project/repository/branches/default.md) (here, using `main`):
 
-1. Fetch the latest changes from `master`:
+1. Fetch the latest changes from `main`:
 
    ```shell
-   git fetch origin master
+   git fetch origin main
    ```
 
 1. Checkout your feature branch:
@@ -94,24 +95,24 @@ For example, to update your branch `my-feature-branch` with `master`:
    git checkout my-feature-branch
    ```
 
-1. Rebase it against `master`:
+1. Rebase it against `main`:
 
    ```shell
-   git rebase origin/master
+   git rebase origin/main
    ```
 
 1. [Force-push](#force-push) to your branch.
 
 When you rebase:
 
-1. Git imports all the commits submitted to `master` _after_ the
+1. Git imports all the commits submitted to `main` _after_ the
    moment you created your feature branch until the present moment.
 1. Git puts the commits you have in your feature branch on top of all
-   the commits imported from `master`:
+   the commits imported from `main`:
 
 ![Git rebase illustration](img/git_rebase_v13_5.png)
 
-You can replace `master` with any other branch you want to rebase against, for
+You can replace `main` with any other branch you want to rebase against, for
 example, `release-10-3`. You can also replace `origin` with other remote
 repositories, for example, `upstream`. To check what remotes you have linked to your local
 repository, you can run `git remote -v`.

doc/topics/git/numerous_undo_possibilities_in_git/index.md

@@ -354,7 +354,7 @@ GitLab). There is a `git merge --squash` command which does exactly that
 at merge).
 
 NOTE:
-Never modify the commit history of `master` or shared branch.
+Never modify the commit history of your [default branch](../../../user/project/repository/branches/default.md) or shared branch.
 
 ### How modifying history is done
 

doc/topics/git/useful_git_commands.md

@@ -180,12 +180,13 @@ Git includes a complete set of [traces for debugging Git commands](https://git-s
 
 ## Rebasing
 
-### Rebase your branch onto master
+### Rebase your branch onto the default
 
-The `-i` flag stands for 'interactive':
+The `-i` flag stands for 'interactive'. Replace `<default-branch>` with the name
+of your [default branch](../../user/project/repository/branches/default.md):
 
 ```shell
-git rebase -i master
+git rebase -i <default-branch>
 ```
 
 ### Continue the rebase if paused

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -17,8 +17,11 @@ To access the visibility and access control options:
 
 ## Default branch protection
 
-This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
-branches. In this case _Default_ refers to a repository's default branch, which in most cases is `master`.
+This global option defines the branch protection that applies to every repository's
+[default branch](../../project/repository/branches/default.md).
+[Branch protection](../../project/protected_branches.md) specifies which roles can push
+to branches and which roles can delete branches. In this case _Default_ refers to a
+repository's [default branch](../../project/repository/branches/default.md).
 
 This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [protected branches](../../project/protected_branches.md).
 

doc/user/project/file_lock.md

@@ -201,8 +201,8 @@ This process allows you to lock one file at a time through the GitLab UI and
 requires access to [GitLab Premium](https://about.gitlab.com/pricing/)
 or higher tiers.
 
-Default branch file and directory locks only apply to the default branch set in
-the project's settings (usually `master`).
+Default branch file and directory locks only apply to the
+[default branch](repository/branches/default.md) set in the project's settings.
 
 Changes to locked files on the default branch are blocked, including merge
 requests that modify locked files. Unlock the file to allow changes.

doc/user/project/highlighting.md

@@ -45,7 +45,7 @@ To disable highlighting entirely, use `gitlab-language=text`. Lots more fun shen
 ```
 
 Please note that these configurations only take effect when the `.gitattributes`
-file is in your default branch (usually `master`).
+file is in your [default branch](repository/branches/default.md).
 
 NOTE:
 The Web IDE does not support `.gitattribute` files, but it's [planned for a future release](https://gitlab.com/gitlab-org/gitlab/-/issues/22014).

doc/user/project/repository/repository_mirroring.md

@@ -93,14 +93,14 @@ You can also create and modify project push mirrors through the
 By default, if any ref on the remote mirror has diverged from the local
 repository, the *entire push* fails, and no updates occur.
 
-For example, if a repository has `master`, `develop`, and `stable` branches that
+For example, if a repository has `main`, `develop`, and `stable` branches that
 have been mirrored to a remote, and then a new commit is added to `develop` on
-the mirror, the next push attempt fails, leaving `master` and `stable`
+the mirror, the next push attempt fails, leaving `main` and `stable`
 out-of-date despite not having diverged. No change on any branch can be mirrored
 until the divergence is resolved.
 
 With the **Keep divergent refs** option enabled, the `develop` branch is
-skipped, allowing `master` and `stable` to be updated. The mirror status
+skipped, allowing `main` and `stable` to be updated. The mirror status
 reflects that `develop` has diverged and was skipped, and be marked as a failed
 update.