Merge branch '326486-create-master-main' into 'master'

Fix master / main change for Code Review docs

See merge request gitlab-org/gitlab!62149

doc/user/project/merge_requests/authorization_for_merge_requests.md

@@ -46,7 +46,7 @@ them from pushing any changes to it.
 Developers create forks of the authoritative project and push their feature
 branches to their own forks.
 
-To get their changes into master they need to create a merge request across
+To get their changes into the default branch, they need to create a merge request across
 forks.
 
 **Advantages**

doc/user/project/merge_requests/getting_started.md

@@ -216,18 +216,18 @@ open merge request, if the destination branch merges while the merge request is
 open. Merge requests are often chained in this manner, with one merge request
 depending on another:
 
-- **Merge request 1**: merge `feature-alpha` into `master`.
+- **Merge request 1**: merge `feature-alpha` into `main`.
 - **Merge request 2**: merge `feature-beta` into `feature-alpha`.
 
 These merge requests are usually handled in one of these ways:
 
-- Merge request 1 is merged into `master` first. Merge request 2 is then
-  retargeted to `master`.
+- Merge request 1 is merged into `main` first. Merge request 2 is then
+  retargeted to `main`.
 - Merge request 2 is merged into `feature-alpha`. The updated merge request 1, which
-  now contains the contents of `feature-alpha` and `feature-beta`, is merged into `master`.
+  now contains the contents of `feature-alpha` and `feature-beta`, is merged into `main`.
 
 GitLab retargets up to four merge requests when their target branch is merged into
-`master`, so you don't need to perform this operation manually. Merge requests from
+`main`, so you don't need to perform this operation manually. Merge requests from
 forks are not retargeted.
 
 The feature today works only on merge. Clicking the **Remove source branch** button

doc/user/project/merge_requests/merge_request_dependencies.md

@@ -38,7 +38,7 @@ For example, given a project `mycorp/awesome-project` that imports a library
 at `myfriend/awesome-lib`, adding a feature in `awesome-project` may **also**
 require changes to `awesome-lib`, and so necessitate two merge requests. Merging
 the `awesome-project` merge request before the `awesome-lib` one would
-break the `master`branch.
+break the default branch.
 
 The `awesome-project` merge request could be [marked as **Draft**](drafts.md),
 and the reason for the draft stated included in the comments. However, this

doc/user/project/merge_requests/resolve_conflicts.md

@@ -39,8 +39,8 @@ highlighted:
 After all conflicts have been marked as using 'ours' or 'theirs', the conflict
 can be resolved. Resolving conflicts merges the target branch of the merge
 request into the source branch, using the options
-chosen. If the source branch is `feature` and the target branch is `master`,
-this is similar to performing `git checkout feature; git merge master` locally.
+chosen. If the source branch is `feature` and the target branch is `main`,
+this is similar to performing `git checkout feature; git merge main` locally.
 
 ## Resolve conflicts: inline editor