Add latest changes from gitlab-org/gitlab@15-0-stable-eev15.0.0-rc42

16 files changed, 54 insertions, 180 deletions

diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index 503774ef6b5..e2d984dbbff 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -26,7 +26,7 @@ used for the build.
 
 Specify either:
 
-- The CI/CD variable `BUILDPACK_URL` according to [`pack`'s specifications](https://buildpacks.io/docs/app-developer-guide/specify-buildpacks/).
+- The CI/CD variable `BUILDPACK_URL` with any of [`pack`'s URI specification formats](https://buildpacks.io/docs/app-developer-guide/specify-buildpacks/).
 - A [`project.toml` project descriptor](https://buildpacks.io/docs/app-developer-guide/using-project-descriptor/) with the buildpacks you would like to include.
 
 ### Custom buildpacks with Herokuish
@@ -431,7 +431,7 @@ applications.
 | `HELM_UPGRADE_EXTRA_ARGS`               | Allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. |
 | `INCREMENTAL_ROLLOUT_MODE`              | If present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
 | `K8S_SECRET_*`                          | Any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) is made available by Auto DevOps as environment variables to the deployed application. |
-| `KUBE_CONTEXT`                          | From GitLab 14.5, can be used to select a context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) is used. A context must be selected when used [with the agent for Kubernetes](../../user/clusters/agent/ci_cd_tunnel.md). |
+| `KUBE_CONTEXT`                          | From GitLab 14.5, can be used to select a context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) is used. A context must be selected when used [with the agent for Kubernetes](../../user/clusters/agent/ci_cd_workflow.md). |
 | `KUBE_INGRESS_BASE_DOMAIN`              | Can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) for more information. |
 | `KUBE_NAMESPACE`                        | The namespace used for deployments. When using certificate-based clusters, [this value should not be overwritten directly](../../user/project/clusters/deploy_to_cluster.md#custom-namespace). |
 | `KUBECONFIG`                            | The kubeconfig to use for deployments. User-provided values take priority over GitLab-provided values. |
@@ -479,7 +479,6 @@ The following table lists variables used to disable jobs.
 | `build_artifact`                       | `BUILD_DISABLED`                |                       | If the variable is present, the job isn't created. |
 | `bandit-sast`                          | `SAST_DISABLED`                 |                       | If the variable is present, the job isn't created. |
 | `brakeman-sast`                        | `SAST_DISABLED`                 |                       | If the variable is present, the job isn't created. |
-| `bundler-audit-dependency_scanning`    | `DEPENDENCY_SCANNING_DISABLED`  |                       | If the variable is present, the job isn't created. |
 | `canary`                               | `CANARY_ENABLED`                |                       | This manual job is created if the variable is present. |
 | `cluster_image_scanning`               | `CLUSTER_IMAGE_SCANNING_DISABLED` |                     | If the variable is present, the job isn't created. |
 | `code_intelligence`                    | `CODE_INTELLIGENCE_DISABLED`    | From GitLab 13.6      | If the variable is present, the job isn't created. |
@@ -503,7 +502,6 @@ The following table lists variables used to disable jobs.
 | `browser_performance`                  | `BROWSER_PERFORMANCE_DISABLED`  | From GitLab 14.0      | Browser performance. If the variable is present, the job isn't created. Replaces `performance`. |
 | `phpcs-security-audit-sast`            | `SAST_DISABLED`                 |                       | If the variable is present, the job isn't created. |
 | `pmd-apex-sast`                        | `SAST_DISABLED`                 |                       | If the variable is present, the job isn't created. |
-| `retire-js-dependency_scanning`        | `DEPENDENCY_SCANNING_DISABLED`  |                       | If the variable is present, the job isn't created. |
 | `review`                               | `REVIEW_DISABLED`               |                       | If the variable is present, the job isn't created. |
 | `review:stop`                          | `REVIEW_DISABLED`               |                       | Manual job. If the variable is present, the job isn't created. |
 | `sast`                                 | `SAST_DISABLED`                 |                       | If the variable is present, the job isn't created. |
diff --git a/doc/topics/autodevops/prepare_deployment.md b/doc/topics/autodevops/prepare_deployment.md
index c23774b1ffd..7c9bf5a770e 100644
--- a/doc/topics/autodevops/prepare_deployment.md
+++ b/doc/topics/autodevops/prepare_deployment.md
@@ -51,7 +51,7 @@ as other environment [variables](../../ci/variables/index.md#cicd-variable-prece
 
 If you don't specify the base domain in your projects and groups, Auto DevOps uses the instance-wide **Auto DevOps domain**.
 
-Auto DevOps requires a wildcard DNS A record matching the base domain(s). For
+Auto DevOps requires a wildcard DNS A record matching the base domains. For
 a base domain of `example.com`, you'd need a DNS entry like:
 
 ```plaintext
diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md
index 13d831aa00d..8d1bf7adc7f 100644
--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@@ -296,7 +296,8 @@ bin/rails test test/controllers/welcome_controller_test.rb:4
 
 To fix the broken test:
 
-1. Return to the **Overview** page for your merge request, and select **Open in Web IDE**.
+1. Return to your merge request.
+1. In the upper right corner, select **Code**, then select **Open in Gitpod**.
 1. In the left-hand directory of files, find the `test/controllers/welcome_controller_test.rb`
    file, and select it to open it.
 1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md
index 816cbbece4f..039d98efd47 100644
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -69,7 +69,7 @@ as other environment [variables](../../ci/variables/index.md#cicd-variable-prece
 
 If you don't specify the base domain in your projects and groups, Auto DevOps uses the instance-wide **Auto DevOps domain**.
 
-Auto DevOps requires a wildcard DNS A record matching the base domain(s). For
+Auto DevOps requires a wildcard DNS `A` record that matches the base domains. For
 a base domain of `example.com`, you'd need a DNS entry like:
 
 ```plaintext
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index 790b46b6310..a677787b980 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -50,7 +50,7 @@ the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
 Each buildpack requires your project's repository to contain certain files for
 Auto Build to build your application successfully. The structure is
 specific to the builder and buildpacks you have selected.
-For example, when using the Heroku's builder (the default), your application's
+For example, when using the Heroku builder (the default), your application's
 root directory must contain the appropriate file for your application's
 language:
 
@@ -240,7 +240,7 @@ To learn more about
 [License Compliance](../../user/compliance/license_compliance/index.md), see the
 documentation.
 
-## Auto Container Scanning **(ULTIMATE)**
+## Auto Container Scanning
 
 Vulnerability static analysis for containers uses [Trivy](https://aquasecurity.github.io/trivy/latest/)
 to check for potential security issues in Docker images. The Auto Container Scanning stage is
@@ -551,129 +551,6 @@ workers:
     terminationGracePeriodSeconds: 60
 ```
 
-### Network Policy
-
-- [Introduced](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/30) in GitLab 12.7.
-- [Deprecated](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/merge_requests/184) in GitLab 13.9.
-
-By default, all Kubernetes pods are
-[non-isolated](https://kubernetes.io/docs/concepts/services-networking/network-policies/#isolated-and-non-isolated-pods),
-and accept traffic to and from any source. You can use
-[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
-to restrict connections to and from selected pods, namespaces, and the Internet.
-
-NOTE:
-You must use a Kubernetes network plugin that implements support for
-`NetworkPolicy`. The default network plugin for Kubernetes (`kubenet`)
-[does not implement](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)
-support for it. The [Cilium](https://cilium.io/) network plugin can be
-installed as a [cluster application](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium)
-to enable support for network policies.
-
-You can enable deployment of a network policy by setting the following
-in the `.gitlab/auto-deploy-values.yaml` file:
-
-```yaml
-networkPolicy:
-  enabled: true
-```
-
-The default policy deployed by the Auto Deploy pipeline allows
-traffic within a local namespace, and from the `gitlab-managed-apps`
-namespace. All other inbound connections are blocked. Outbound
-traffic (for example, to the Internet) is not affected by the default policy.
-
-You can also provide a custom [policy specification](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
-in the `.gitlab/auto-deploy-values.yaml` file, for example:
-
-```yaml
-networkPolicy:
-  enabled: true
-  spec:
-    podSelector:
-      matchLabels:
-        app.gitlab.com/env: staging
-    ingress:
-      - from:
-        - podSelector:
-            matchLabels: {}
-        - namespaceSelector:
-            matchLabels:
-              app.gitlab.com/managed_by: gitlab
-```
-
-For more information on installing Network Policies, see
-[Use the Cluster Management Template to Install Cilium](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium).
-
-### Cilium Network Policy
-
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/merge_requests/184) in GitLab 13.9.
-
-By default, all Kubernetes pods are
-[non-isolated](https://kubernetes.io/docs/concepts/services-networking/network-policies/#isolated-and-non-isolated-pods),
-and accept traffic to and from any source. You can use
-[CiliumNetworkPolicy](https://docs.cilium.io/en/v1.8/concepts/kubernetes/policy/#ciliumnetworkpolicy)
-to restrict connections to and from selected pods, namespaces, and the internet.
-
-#### Requirements
-
-As the default network plugin for Kubernetes (`kubenet`)
-[does not implement](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)
-support for it, you must have [Cilium](https://docs.cilium.io/en/v1.8/intro/) as your Kubernetes network plugin.
-
-The [Cilium](https://cilium.io/) network plugin can be
-installed with a [cluster management project template](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium)
-to enable support for network policies.
-
-#### Configuration
-
-You can enable deployment of a network policy by setting the following
-in the `.gitlab/auto-deploy-values.yaml` file:
-
-```yaml
-ciliumNetworkPolicy:
-  enabled: true
-```
-
-The default policy deployed by the Auto Deploy pipeline allows
-traffic within a local namespace, and from the `gitlab-managed-apps`
-namespace. All other inbound connections are blocked. Outbound
-traffic (for example, to the internet) is not affected by the default policy.
-
-You can also provide a custom [policy specification](https://docs.cilium.io/en/v1.8/policy/language/#simple-ingress-allow)
-in the `.gitlab/auto-deploy-values.yaml` file, for example:
-
-```yaml
-ciliumNetworkPolicy:
-  enabled: true
-  spec:
-    endpointSelector:
-      matchLabels:
-        app.gitlab.com/env: staging
-    ingress:
-      - fromEndpoints:
-        - matchLabels:
-            app.gitlab.com/managed_by: gitlab
-```
-
-#### Enabling Alerts
-
-You can also enable alerts. Network policies with alerts are considered only if
-the [agent](../../user/clusters/agent/index.md)
-has been integrated.
-
-You can enable alerts as follows:
-
-```yaml
-ciliumNetworkPolicy:
-  enabled: true
-  alerts:
-    enabled: true
-```
-
-For more information on installing Network Policies, see
-[Use the Cluster Management Template to Install Cilium](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium).
-
 ### Running commands in the container
 
 Applications built with [Auto Build](#auto-build) using Herokuish, the default
diff --git a/doc/topics/git/feature_branching.md b/doc/topics/git/feature_branching.md
index f0ded5511ee..d3b2510f4e8 100644
--- a/doc/topics/git/feature_branching.md
+++ b/doc/topics/git/feature_branching.md
@@ -12,7 +12,7 @@ comments: false
 - Keeps changes isolated
 - Consider a 1-to-1 link to issues
 - Push branches to the server frequently
-  - Hint: This is a cheap backup for your work-in-progress code
+  - Hint: Pushing branches is a cheap backup for your work-in-progress code.
 
 ## Feature branching sample workflow
 
diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md
index c0bc7ed4e5c..87fce0b29ff 100644
--- a/doc/topics/git/git_rebase.md
+++ b/doc/topics/git/git_rebase.md
@@ -17,7 +17,7 @@ Before diving into this document, make sure you are familiar with using
 ## Git rebase
 
 [Rebasing](https://git-scm.com/docs/git-rebase) is a very common operation in
-Git. There are the following rebase options:
+Git, and has these options:
 
 - [Regular rebase](#regular-rebase).
 - [Interactive rebase](#interactive-rebase).
@@ -69,15 +69,15 @@ changes by resetting `my-feature-branch` against `my-feature-branch-backup`:
    git reset --hard my-feature-branch-backup
    ```
 
-Note that if you added changes to `my-feature-branch` after creating the backup branch,
+If you added changes to `my-feature-branch` after creating the backup branch,
 you lose them when resetting.
 
 ### Regular rebase
 
 With a regular rebase you can update your feature branch with the default
 branch (or any other branch).
-This is an important step for Git-based development strategies. You can
-ensure that the changes you're adding to the codebase do not break any
+This step is important for Git-based development strategies. You can
+ensure your new changes don't break any
 existing changes added to the target branch _after_ you created your feature
 branch.
 
@@ -148,7 +148,7 @@ executes it as soon as possible.
 The user performing the rebase action is considered
 a user that added commits to the merge request. When the merge request approvals setting
 [**Prevent approvals by users who add commits**](../../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits)
-is enabled, this setting prevents the user from also approving the merge request.
+is enabled, the user can't also approve the merge request.
 
 ### Interactive rebase
 
@@ -158,7 +158,7 @@ commits. Use a rebase for changing past commit messages,
 and organizing the commit history of your branch to keep it clean.
 
 NOTE:
-If you want to keep the default branch commit history clean, you don't need to
+Keeping the default branch commit history clean doesn't require you to
 manually squash all your commits before merging every merge request.
 With [Squash and Merge](../../user/project/merge_requests/squash_and_merge.md),
 GitLab does it automatically.
@@ -176,18 +176,17 @@ git rebase -i HEAD~3
 Git opens the last three commits in your terminal text editor and describes
 all the interactive rebase options you can use. The default option is `pick`,
 which maintains the commit unchanged. Replace the keyword `pick` according to
-the operation you want to perform in each commit. To do so, you need to edit
+the operation you want to perform in each commit. To do so, edit
 the commits in your terminal's text editor.
 
-For example, if you're using [Vim](https://www.vim.org/) as the text editor in
-a macOS's `ZSH` shell, and you want to `squash` or `fixup` all the three commits
-(join them into one):
+For example, with [Vim](https://www.vim.org/) as the text editor in
+a macOS's `ZSH` shell, you can `squash` or `fixup` (combine) all three commits:
 
 <!-- vale gitlab.FirstPerson = NO -->
 
 1. Press <kbd>i</kbd>
    on your keyboard to switch to Vim's editing mode.
-1. Navigate with your keyboard arrows to edit the **second** commit keyword
+1. Use your keyboard arrows to edit the **second** commit keyword
    from `pick` to `squash` or `fixup` (or `s` or `f`). Do the same to the **third** commit.
    The first commit should be left **unchanged** (`pick`) as we want to squash
    the second and third into the first.
@@ -204,7 +203,7 @@ a macOS's `ZSH` shell, and you want to `squash` or `fixup` all the three commits
 
 <!-- vale gitlab.FirstPerson = YES -->
 
-Note that the steps for editing through the command line can be slightly
+The steps for editing through the command line can be slightly
 different depending on your operating system and the shell you're using.
 
 See [Numerous undo possibilities in Git](numerous_undo_possibilities_in_git/index.md#undo-staged-local-changes-without-modifying-history)
@@ -226,8 +225,8 @@ Forcing an update is **not** recommended when you're working on shared
 branches.
 
 Alternatively, you can pass the flag [`--force-with-lease`](https://git-scm.com/docs/git-push#Documentation/git-push.txt---force-with-leaseltrefnamegt)
-instead. It is safer, as it does not overwrite any work on the remote
-branch if more commits were added to the remote branch by someone else:
+instead, as it is safer. This flag preserves any new commits added to the remote
+branch by other people:
 
 ```shell
 git push --force-with-lease origin my-feature-branch
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index db63cee3523..410d2150de5 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -45,7 +45,7 @@ Documentation for GitLab instance administrators is under [LFS administration do
 
 ## Using Git LFS
 
-Let's take a look at the workflow when you need to check large files into your Git
+Let's take a look at the workflow for checking large files into your Git
 repository with Git LFS. For example, if you want to upload a very large file and
 check it into your Git repository:
 
@@ -130,10 +130,10 @@ Technical details about how this works can be found in the [development document
 
 ## Troubleshooting
 
-### Encountered `n` file(s) that should have been pointers, but weren't
+### Encountered `n` files that should have been pointers, but weren't
 
-This error indicates the file (or files) are expected to be tracked by LFS, but for
-some reason the repository is not tracking them as LFS. This issue can be one
+This error indicates the files are expected to be tracked by LFS, but
+the repository is not tracking them as LFS. This issue can be one
 potential reason for this error:
 [Files not tracked with LFS when uploaded through the web interface](https://gitlab.com/gitlab-org/gitlab/-/issues/326342#note_586820485)
 
@@ -160,7 +160,7 @@ To resolve the problem, migrate the affected file (or files) and push back to th
 
 ### error: Repository or object not found
 
-There are a couple of reasons why this error can occur:
+This error can occur for a few reasons, including:
 
 - You don't have permissions to access certain LFS object
 
@@ -232,7 +232,7 @@ Git LFS authenticates the user with HTTP Basic Authentication on every push for
 every object, so user HTTPS credentials are required.
 
 By default, Git has support for remembering the credentials for each repository
-you use. This is described in [Git credentials man pages](https://git-scm.com/docs/gitcredentials).
+you use. To learn more, read the [Git credentials man pages](https://git-scm.com/docs/gitcredentials).
 
 For example, you can tell Git to remember the password for a period of time in
 which you expect to push the objects:
diff --git a/doc/topics/git/merge_conflicts.md b/doc/topics/git/merge_conflicts.md
index 47276ccb0b2..03b7c03c02a 100644
--- a/doc/topics/git/merge_conflicts.md
+++ b/doc/topics/git/merge_conflicts.md
@@ -14,12 +14,12 @@ comments: false
 
 ## Merge conflicts sample workflow
 
-1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
+1. Check out a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
 1. Commit and push.
-1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
-1. Commit and push to master.
+1. Check out `main` and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to `main``.
 1. Create a merge request and watch it fail.
-1. Rebase our new branch with master.
+1. Rebase our new branch with `main`.
 1. Fix conflicts on the `conflicts.rb` file.
 1. Stage the file and continue rebasing.
 1. Force push the changes.
@@ -34,12 +34,12 @@ git checkout -b conflicts_branch
 git commit -am "add line4 and line5"
 git push origin conflicts_branch
 
-git checkout master
+git checkout main
 
 # vi conflicts.rb
 # Add 'Line6' and 'Line7'
 git commit -am "add line6 and line7"
-git push origin master
+git push origin main
 ```
 
 Create a merge request on the GitLab web UI, and a conflict warning displays.
@@ -47,7 +47,7 @@ Create a merge request on the GitLab web UI, and a conflict warning displays.
 ```shell
 git checkout conflicts_branch
 git fetch
-git rebase master
+git rebase main
 
 # Fix conflicts by editing the files.
 
@@ -64,6 +64,6 @@ git push origin conflicts_branch -f
 ## Note
 
 - When to use `git merge` and when to use `git rebase`
-- Rebase when updating your branch with master
-- Merge when bringing changes from feature to master
+- Rebase when updating your branch with `main`
+- Merge when bringing changes from feature to `main`
 - Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>
diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md
index cad29d30af4..91ff4d69c2f 100644
--- a/doc/topics/git/partial_clone.md
+++ b/doc/topics/git/partial_clone.md
@@ -26,7 +26,7 @@ Git 2.22.0 or later is required.
 
 Storing large binary files in Git is normally discouraged, because every large
 file added is downloaded by everyone who clones or fetches changes
-thereafter. This is slow, if not a complete obstruction when working from a slow
+thereafter. These downloads are slow and problematic, especially when working from a slow
 or unreliable internet connection.
 
 Using partial clone with a file size filter solves this problem, by excluding
@@ -65,7 +65,7 @@ The output is longer because Git:
 1. Clones the repository excluding files larger than 1 megabyte.
 1. Downloads any missing large files needed to check out the default branch.
 
-When changing branches, Git may need to download more missing files.
+When changing branches, Git may download more missing files.
 
 ## Filter by object type
 
@@ -147,7 +147,7 @@ For more details, see the Git documentation for
    ```
 
 1. Clone and filter by path. Support for `--filter=sparse:oid` using the
-   clone command is not yet fully integrated with sparse checkout.
+   clone command is not fully integrated with sparse checkout.
 
    ```shell
 
@@ -162,8 +162,7 @@ For more details, see the Git documentation for
    WARNING:
    Git integrations with `bash`, `zsh`, etc and editors that automatically
    show Git status information often run `git fetch` which fetches the
-   entire repository. You many need to disable or reconfigure these
-   integrations.
+   entire repository. Disabling or reconfiguring these integrations might be required.
 
 ## Remove partial clone filtering
 
diff --git a/doc/topics/git/stash.md b/doc/topics/git/stash.md
index d321795e034..638ab559bd3 100644
--- a/doc/topics/git/stash.md
+++ b/doc/topics/git/stash.md
@@ -7,8 +7,8 @@ comments: false
 
 # Git Stash **(FREE)**
 
-We use `git stash` to store our changes when they are not ready to be committed
-and we need to change to a different branch.
+We use `git stash` to store our changes when they are not ready to be committed,
+but we must change to a different branch.
 
 - Stash:
 
@@ -37,7 +37,7 @@ and we need to change to a different branch.
   git stash list --stat
   ```
 
-- To clean our stack we need to manually remove them:
+- To clean our stack, manually remove them:
 
   ```shell
   # drop top stash
@@ -54,7 +54,7 @@ and we need to change to a different branch.
   git stash pop
   ```
 
-- If we meet conflicts we need to either reset or commit our changes.
+- If we meet conflicts, either reset or commit our changes.
 - Conflicts through `pop` doesn't drop a stash afterwards.
 
 ## Git Stash sample workflow
diff --git a/doc/topics/git/tags.md b/doc/topics/git/tags.md
index 8576bcd09ed..d3237fda968 100644
--- a/doc/topics/git/tags.md
+++ b/doc/topics/git/tags.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Tags **(FREE)**
 
-Tags are useful for marking certain deployments and releases for later
+Tags help you mark certain deployments and releases for later
 reference. Git supports two types of tags:
 
 - Annotated tags: An unchangeable part of Git history.
diff --git a/doc/topics/git/terminology.md b/doc/topics/git/terminology.md
index 35814543934..4ce87aa2d11 100644
--- a/doc/topics/git/terminology.md
+++ b/doc/topics/git/terminology.md
@@ -30,7 +30,7 @@ When you want to contribute to someone else's repository, you make a copy of it.
 This copy is called a [**fork**](../../user/project/repository/forking_workflow.md#creating-a-fork).
 The process is called "creating a fork."
 
-When you fork a repo, you create a copy of the project in your own
+When you fork a repository, you create a copy of the project in your own
 [namespace](../../user/group/#namespaces). You then have write permissions to modify the project files
 and settings.
 
@@ -53,10 +53,10 @@ upload the changes to the remote repository on GitLab.
 ## Pull and push
 
 After you save a local copy of a repository and modify the files on your computer, you can upload the
-changes to GitLab. This is referred to as **pushing** to the remote, because you use the command
+changes to GitLab. This action is known as **pushing** to the remote, because you use the command
 [`git push`](../../gitlab-basics/start-using-git.md#send-changes-to-gitlabcom).
 
 When the remote repository changes, your local copy is behind. You can update your local copy with the new
 changes in the remote repository.
-This is referred to as **pulling** from the remote, because you use the command
+This action is known as **pulling** from the remote, because you use the command
 [`git pull`](../../gitlab-basics/start-using-git.md#download-the-latest-changes-in-the-project).
diff --git a/doc/topics/git/troubleshooting_git.md b/doc/topics/git/troubleshooting_git.md
index 0aadde7f7c2..13962ad0376 100644
--- a/doc/topics/git/troubleshooting_git.md
+++ b/doc/topics/git/troubleshooting_git.md
@@ -214,7 +214,7 @@ apply more than one:
      ```shell
      omnibus_gitconfig['system'] = {
        # Set the http.postBuffer size, in bytes
-       "http" => ["postBuffer => 524288000"]
+       "http" => ["postBuffer = 524288000"]
      }
      ```
 
diff --git a/doc/topics/git/useful_git_commands.md b/doc/topics/git/useful_git_commands.md
index 61f170d934a..13a40dd58ca 100644
--- a/doc/topics/git/useful_git_commands.md
+++ b/doc/topics/git/useful_git_commands.md
@@ -8,7 +8,7 @@ type: reference
 # Useful Git commands **(FREE)**
 
 The GitLab support team has collected these commands to help you. You may not
-need to use them often.
+need them frequently.
 
 ## Remotes
 
@@ -42,7 +42,7 @@ git reset <filename>
 
 ### Revert a file to HEAD state and remove changes
 
-There are two options to revert changes to a file:
+To revert changes to a file, you can use either:
 
 - `git checkout <filename>`
 - `git reset --hard <filename>`
diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md
index c791b1f7185..6c94e9e78f9 100644
--- a/doc/topics/release_your_application.md
+++ b/doc/topics/release_your_application.md
@@ -37,7 +37,7 @@ approach to manage Kubernetes deployments.
 #### Deploy to Kubernetes from GitLab CI/CD
 
 With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform [push-based
-deployments](../user/clusters/agent/ci_cd_tunnel.md) from GitLab CI/CD. The agent provides
+deployments](../user/clusters/agent/ci_cd_workflow.md) from GitLab CI/CD. The agent provides
 a secure and reliable connection between GitLab and your Kubernetes cluster.
 
 ### Deploy to AWS with GitLab CI/CD
@@ -67,5 +67,5 @@ Use [feature flags](../operations/feature_flags.md) to control and strategically
 
 ## Deploy to Google Cloud
 
-GitLab [Cloud Seed](../cloud_seed/index.md) is an open-source Incubation Engineering program that 
+GitLab [Cloud Seed](../cloud_seed/index.md) is an open-source Incubation Engineering program that
 enables you to set up deployment credentials and deploy your application to Google Cloud Run with minimal friction.