Merge branch 'docs-replace-master-default-configure-1' into 'master'

Docs: Replaces master with main or default branch (Configure)

See merge request gitlab-org/gitlab!64231

doc/ci/chatops/index.md

@@ -33,7 +33,7 @@ to the job:
 
 When executed, ChatOps looks up the specified job name and attempts to match it
 to a corresponding job in [`.gitlab-ci.yml`](../yaml/README.md). If a matching job
-is found on `master`, a pipeline containing only that job is scheduled. After the
+is found on the default branch, a pipeline containing only that job is scheduled. After the
 job completes:
 
 - If the job completes in *less than 30 minutes*, the ChatOps sends the job's output to Slack.

doc/topics/autodevops/quick_start_guide.md

@@ -155,7 +155,7 @@ these steps to enable Auto DevOps if it's disabled:
 1. Navigate to **Settings > CI/CD > Auto DevOps**, and click **Expand**.
 1. Select **Default to Auto DevOps pipeline** to display more options.
 1. In **Deployment strategy**, select your desired [continuous deployment strategy](index.md#deployment-strategy)
-   to deploy the application to production after the pipeline successfully runs on the `master` branch.
+   to deploy the application to production after the pipeline successfully runs on the default branch.
 1. Click **Save changes**.
 
    ![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
@@ -199,7 +199,7 @@ The jobs are separated into stages:
     licenses and is allowed to fail
     ([Auto License Compliance](stages.md#auto-license-compliance)) **(ULTIMATE)**
 
-- **Review** - Pipelines on `master` include this stage with a `dast_environment_deploy` job.
+- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
   To learn more, see [Dynamic Application Security Testing (DAST)](../../user/application_security/dast/index.md).
 
 - **Production** - After the tests and checks finish, the application deploys in
@@ -208,7 +208,7 @@ The jobs are separated into stages:
 - **Performance** - Performance tests are run on the deployed application
   ([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)). **(PREMIUM)**
 
-- **Cleanup** - Pipelines on `master` include this stage with a `stop_dast_environment` job.
+- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job.
 
 After running a pipeline, you should view your deployed website and learn how
 to monitor it.
@@ -267,7 +267,7 @@ you should next create a feature branch to add content to your application:
 
 After submitting the merge request, GitLab runs your pipeline, and all the jobs
 in it, as [described previously](#deploy-the-application), in addition to
-a few more that run only on branches other than `master`.
+a few more that run only on branches other than the default branch.
 
 ![Merge request](img/guide_merge_request_v12_3.png)
 
@@ -303,7 +303,7 @@ the **View app** **{external-link}** button to see your changes deployed.
 
 ![Review app](img/guide_merge_request_review_app_v12_3.png)
 
-After merging the merge request, GitLab runs the pipeline on the `master` branch,
+After merging the merge request, GitLab runs the pipeline on the default branch,
 and then deploys the application to production.
 
 ## Conclusion

doc/topics/autodevops/stages.md

@@ -350,8 +350,7 @@ Any load performance test result differences between the source and target branc
 
 Auto Deploy is an optional step for Auto DevOps. If the [requirements](requirements.md) are not met, the job is skipped.
 
-After a branch or merge request is merged into the project's default branch (usually
-`master`), Auto Deploy deploys the application to a `production` environment in
+After a branch or merge request is merged into the project's default branch, Auto Deploy deploys the application to a `production` environment in
 the Kubernetes cluster, with a namespace based on the project name and unique
 project ID, such as `project-4321`.
 

doc/topics/autodevops/upgrading_postgresql.md

@@ -195,7 +195,7 @@ higher*. This is the
    remove the variables, or rename the variables temporarily to
    `XDB_INITIALIZE` or the `XDB_MIGRATE` to effectively disable them.
 1. Run a new CI pipeline for the branch. In this case, we run a new CI
-   pipeline for `master`.
+   pipeline for `main`.
 1. After the pipeline is successful, your application is upgraded
    with the new PostgreSQL installed. Zero replicas exist at this time, so
    no traffic is served for your application (to prevent
@@ -250,5 +250,5 @@ steps to reinstate your application:
    removed or disabled.
 1. Restore the `PRODUCTION_REPLICAS` or `REPLICAS` variable to its original value.
 1. Run a new CI pipeline for the branch. In this case, we run a new CI
-   pipeline for `master`. After the pipeline is successful, your
+   pipeline for `main`. After the pipeline is successful, your
    application should be serving traffic as before.