Updating docs to match UI text

Related to: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53323

doc/api/deploy_keys.md

@@ -4,7 +4,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Deploy Keys API
+# Deploy keys API
 
 ## List all deploy keys
 

doc/ci/environments/protected_environments.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: concepts, howto
 ---
 
-# Protected Environments **(PREMIUM)**
+# Protected environments **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6303) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
 
@@ -31,7 +31,7 @@ To protect, update, or unprotect an environment, you need to have at least
 To protect an environment:
 
 1. Navigate to your project's **Settings > CI/CD**.
-1. Expand the **Protected Environments** section.
+1. Expand the **Protected environments** section.
 1. From the **Environment** dropdown menu, select the environment you want to protect.
 1. In the **Allowed to Deploy** dropdown menu, select the role, users, or groups you
    want to give deploy access to. Keep in mind that:

doc/push_rules/push_rules.md

@@ -80,7 +80,7 @@ GitLab administrators can set push rules globally under
 **Admin Area > Push Rules** that all new projects inherit. You can later
 override them in a project's settings. They can be also set on a [group level](../user/group/index.md#group-push-rules).
 
-1. Navigate to your project's **Settings > Repository** and expand **Push Rules**
+1. Navigate to your project's **Settings > Repository** and expand **Push rules**
 1. Set the rule you want
 1. Click **Save Push Rules** for the changes to take effect
 

doc/ssh/README.md

@@ -379,7 +379,7 @@ git remote set-url origin git@<user_1.gitlab.com>:gitlab-org/gitlab.git
 
 ## Deploy keys
 
-Read the [documentation on Deploy Keys](../user/project/deploy_keys/index.md).
+Read the [documentation on deploy keys](../user/project/deploy_keys/index.md).
 
 ## Applications
 

doc/topics/git/lfs/migrate_to_git_lfs.md

@@ -115,7 +115,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    so that we can force-push the rewritten repository:
 
    1. Navigate to your project's **Settings > Repository** and
-   expand **Protected Branches**.
+   expand **Protected branches**.
    1. Scroll down to locate the protected branches and click
    **Unprotect** the default branch.
 
@@ -153,7 +153,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
 1. [Re-protect the default branch](../../../user/project/protected_branches.md):
 
    1. Navigate to your project's **Settings > Repository** and
-   expand **Protected Branches**.
+   expand **Protected branches**.
    1. Select the default branch from the **Branch** dropdown menu,
    and set up the
    **Allowed to push** and **Allowed to merge** rules.

doc/user/admin_area/index.md

@@ -31,9 +31,9 @@ The Admin Area is made up of the following sections:
 | **{slight-frown}** Abuse Reports               | Manage [abuse reports](abuse_reports.md) submitted by your users.                                                                                                                                                                                                                        |
 | **{license}** License **(STARTER ONLY)**       | Upload, display, and remove [licenses](license.md).                                                                                                                                                                                                                                      |
 | **{cloud-gear}** Kubernetes                    | Create and manage instance-level [Kubernetes clusters](../instance/clusters/index.md).                                                                                                                                                                                                   |
-| **{push-rules}** Push Rules **(STARTER ONLY)** | Configure pre-defined Git [push rules](../../push_rules/push_rules.md) for projects. Also, configure [merge requests approvers rules](merge_requests_approvals.md). **(PREMIUM SELF)**                                                                                                   |
+| **{push-rules}** Push rules **(STARTER ONLY)** | Configure pre-defined Git [push rules](../../push_rules/push_rules.md) for projects. Also, configure [merge requests approvers rules](merge_requests_approvals.md). **(PREMIUM SELF)**                                                                                                   |
 | **{location-dot}** Geo **(PREMIUM SELF)**      | Configure and maintain [Geo nodes](geo_nodes.md).                                                                                                                                                                                                                                        |
-| **{key}** Deploy Keys                          | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys).                                                                                                                                                                                                                 |
+| **{key}** Deploy keys                          | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys).                                                                                                                                                                                                                 |
 | **{lock}** Credentials **(ULTIMATE SELF)**     | View [credentials](credentials_inventory.md) that can be used to access your instance.                                                                                                                                                                                                   |
 | **{template}** Service Templates               | Create [service templates](../project/integrations/services_templates.md) for projects.                                                                                                                                                                                                  |
 | **{labels}** Labels                            | Create and maintain [labels](labels.md) for your GitLab instance.                                                                                                                                                                                                                        |

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -20,7 +20,7 @@ To access the visibility and access control options:
 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 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).
+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).
 
 To change the default branch protection:
 

doc/user/permissions.md

@@ -189,7 +189,7 @@ The following table depicts the various user permission levels in a project.
 1. Guest users are able to perform this action on public and internal projects, but not private projects. This doesn't apply to [external users](#external-users) where explicit access must be given even if the project is internal.
 1. Guest users can only view the confidential issues they created themselves.
 1. If **Public pipelines** is enabled in **Project Settings > CI/CD**.
-1. Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See [Protected Branches](project/protected_branches.md).
+1. Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See [protected branches](project/protected_branches.md).
 1. If the [branch is protected](project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings), this depends on the access Developers and Maintainers are given.
 1. Guest users can access GitLab [**Releases**](project/releases/index.md) for downloading assets but are not allowed to download the source code nor see repository information like tags and commits.
 1. Actions are limited only to records owned (referenced) by user.

doc/user/project/clusters/index.md

@@ -357,7 +357,7 @@ By default, anyone who can create a deployment job can access any CI variable in
 an environment's deployment job. This includes `KUBECONFIG`, which gives access to
 any secret available to the associated service account in your cluster.
 To keep your production credentials safe, consider using
-[Protected Environments](../../../ci/environments/protected_environments.md),
+[protected environments](../../../ci/environments/protected_environments.md),
 combined with either
 
 - a GitLab-managed cluster and namespace per environment,

doc/user/project/code_owners.md

@@ -97,7 +97,7 @@ without using [Approval Rules](merge_requests/merge_request_approvals.md#approva
 1. Use [the syntax of Code Owners files](code_owners.md#the-syntax-of-code-owners-files)
    to specify the actual owners and granular permissions.
 
-Using Code Owners in conjunction with [Protected Branches](protected_branches.md#protected-branches-approval-by-code-owners)
+Using Code Owners in conjunction with [protected branches](protected_branches.md#protected-branches-approval-by-code-owners)
 prevents any user who is not specified in the `CODEOWNERS` file from pushing
 changes for the specified files/paths, except those included in the
 **Allowed to push** column. This allows for a more inclusive push strategy, as

doc/user/project/deploy_keys/index.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto, reference
 ---
 
-# Deploy Keys
+# Deploy keys
 
 Deploy keys allow read-only or read-write access to your
 repositories by importing an SSH public key into your GitLab instance.
@@ -21,7 +21,7 @@ There are two types of deploy keys:
 
 ## Key details on deploy keys
 
-Deploy Keys allow a remote machine (VM, physical, and so on) to access a GitLab
+Deploy keys allow a remote machine (VM, physical, and so on) to access a GitLab
 repository with just a few steps. If you want a remote machine to interact with a GitLab
 repository in automation, it's a simple solution.
 
@@ -35,7 +35,7 @@ If this security implication is a concern for your organization,
 [Deploy Tokens](../deploy_tokens/index.md) works as an alternative, but with more
 security control.
 
-## Deploy Keys Permissions
+## Deploy keys permissions
 
 You can choose the access level of a deploy key when you enable it on a project:
 
@@ -72,7 +72,7 @@ help you access a repository, but there are some notables differences between th
   on it, but this [is possible with deploy tokens](../deploy_tokens/index.md#gitlab-deploy-token).
 - You need an SSH key pair to use deploy keys, but not deploy tokens.
 
-## How to enable Deploy Keys
+## How to enable deploy keys
 
 ### Project deploy keys
 
@@ -80,17 +80,17 @@ help you access a repository, but there are some notables differences between th
 can add or enable a deploy key for a project repository:
 
 1. Navigate to the project's **Settings > Repository** page.
-1. Expand the **Deploy Keys** section.
+1. Expand the **Deploy keys** section.
 1. Specify a title for the new deploy key and paste your public SSH key.
 1. (Optional) Check **Grant write permissions to this key** to allow `read-write` access. Leave it unchecked for `read-only` access.
 
-There are three lists of Project Deploy Keys:
+There are three lists of project deploy keys:
 
 - Enabled deploy keys
 - Privately accessible deploy keys
 - Public accessible deploy keys
 
-![Deploy Keys section](img/deploy_keys_v13_0.png)
+![Deploy keys section](img/deploy_keys_v13_0.png)
 
 After you add a key, it's enabled for this project by default and it appears
 in the **Enabled deploy keys** tab.
@@ -129,7 +129,7 @@ Instance administrators can add public deploy keys:
    if the key gives access to a SaaS CI/CD instance, use the name of that service
    in the key name if that is all the key is used for.
 
-![Public Deploy Keys section](img/public_deploy_key_v13_0.png)
+![Public deploy keys section](img/public_deploy_key_v13_0.png)
 
 After adding a key, it's available to any shared systems. Project maintainers
 or higher can [authorize a public deploy key](#project-deploy-keys) to start using it with the project.
@@ -153,7 +153,7 @@ until a project maintainer chooses to make use of it.
 
 ## Troubleshooting
 
-### Deploy Key cannot push to a protected branch
+### Deploy key cannot push to a protected branch
 
 If the owner of this deploy key doesn't have access to a [protected
 branch](../protected_branches.md), then this deploy key doesn't have access to

doc/user/project/merge_requests/merge_request_approvals.md

@@ -124,7 +124,7 @@ users with Developer or higher permissions, as well as by Code Owners,
 indistinguishably.
 
 Alternatively, you can **require**
-[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
+[Code Owner's approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
 
 #### Merge Request approval segregation of duties
 
@@ -227,7 +227,7 @@ reduces the number of approvals left for all rules that the approver belongs to.
 
 ![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png)
 
-#### Scoped to Protected Branch **(PREMIUM)**
+#### Scoped to protected branch **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/460) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.8.
 
@@ -239,7 +239,7 @@ the **Target branch** dropdown.
 
 Alternatively, you can select a very specific protected branch from the **Target branch** dropdown:
 
-![Scoped to Protected Branch](img/scoped_to_protected_branch_v12_8.png)
+![Scoped to protected branch](img/scoped_to_protected_branch_v12_8.png)
 
 To enable this configuration, see [Code Owner’s approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners).
 

doc/user/project/protected_branches.md

@@ -76,13 +76,13 @@ dropdown list in the **Already protected** area.
 If you don't choose any of those options while creating a protected branch,
 they are set to Maintainers by default.
 
-### Allow Deploy Keys to push to a protected branch
+### Allow deploy keys to push to a protected branch
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30769) in GitLab 13.7.
 > - This feature is being selectively deployed in GitLab.com 13.7, and may not be available for all users.
 
 You can allow specific machines to access protected branches in your repository with
-[Deploy Keys](deploy_keys/index.md). This can be useful for your CI/CD workflow,
+[deploy keys](deploy_keys/index.md). This can be useful for your CI/CD workflow,
 for example.
 
 Deploy keys can be selected in the **Allowed to push** dropdown when:
@@ -99,9 +99,9 @@ For a deploy key to be selectable:
 - It must be [enabled for your project](deploy_keys/index.md#how-to-enable-deploy-keys).
 - It must have [write access](deploy_keys/index.md#deploy-keys-permissions) to your project repository.
 
-Deploy Keys are not available in the **Allowed to merge** dropdown.
+Deploy keys are not available in the **Allowed to merge** dropdown.
 
-![Deploy Keys on protected branches](img/protected_branches_deploy_keys_v13_5.png)
+![Deploy keys on protected branches](img/protected_branches_deploy_keys_v13_5.png)
 
 ## Restricting push and merge access to certain users **(PREMIUM)**
 
@@ -176,7 +176,7 @@ Deleting a protected branch is allowed only by using the web interface; not from
 This means that you can't accidentally delete a protected branch from your
 command line or a Git client application.
 
-## Protected Branches approval by Code Owners **(PREMIUM)**
+## Protected branches approval by Code Owners **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13251) in GitLab Premium 12.4.
 

doc/user/project/repository/repository_mirroring.md

@@ -340,7 +340,7 @@ If you're mirroring over SSH (that is, using an `ssh://` URL), you can authentic
 
 - Password-based authentication, just as over HTTPS.
 - Public key authentication. This is often more secure than password authentication,
-  especially when the other repository supports [Deploy Keys](../../../ssh/README.md#deploy-keys).
+  especially when the other repository supports [deploy keys](../../../ssh/README.md#deploy-keys).
 
 To get started:
 
@@ -401,7 +401,7 @@ GitLab generates a 4096-bit RSA key that can be copied by clicking the **Copy SS
 You then need to add the public SSH key to the other repository's configuration:
 
 - If the other repository is hosted on GitLab, you should add the public SSH key
-  as a [Deploy Key](../../../ssh/README.md#deploy-keys).
+  as a [deploy key](../../../ssh/README.md#deploy-keys).
 - If the other repository is hosted elsewhere, you may need to add the key to
   your user's  `authorized_keys` file. Paste the entire public SSH key into the
   file on its own line and save it.