Add latest changes from gitlab-org/gitlab@16-7-stable-eev16.7.0-rc42

40 files changed, 668 insertions, 753 deletions

diff --git a/doc/topics/autodevops/cicd_variables.md b/doc/topics/autodevops/cicd_variables.md
index 4fa2ee10c75..9d50d0dabab 100644
--- a/doc/topics/autodevops/cicd_variables.md
+++ b/doc/topics/autodevops/cicd_variables.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # CI/CD variables
@@ -133,7 +133,7 @@ Auto DevOps detects CI/CD variables starting with `K8S_SECRET_`,
 and makes them available to the deployed application as
 environment variables.
 
-Prerequisite:
+Prerequisites:
 
 - The variable value must be a single line.
 
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md
index 381326d68ea..b43d334380b 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Use Auto DevOps to deploy to EC2
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md
index 6ac8f87940e..80079a15ed5 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Use Auto DevOps to deploy to Amazon ECS
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md
index d0a7814348c..486b1334a82 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Use Auto DevOps to deploy an application to Amazon Elastic Kubernetes Service (EKS)
@@ -178,8 +178,6 @@ The jobs are separated into stages:
   - Jobs suffixed with `-sast` run static analysis on the current code to check for potential
     security issues, and are allowed to fail ([Auto SAST](../stages.md#auto-sast))
   - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](../stages.md#auto-secret-detection))
-  - The `license_scanning` job is deprecated and does not produce any results. It is allowed to fail
-    ([Auto License Compliance](../stages.md#auto-license-compliance-deprecated))
 
 - **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).
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
index d50bdcfa056..572e08f355b 100644
--- a/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
+++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Use Auto DevOps to deploy an application to Google Kubernetes Engine **(FREE ALL)**
@@ -77,7 +77,7 @@ Now you have an application project you are going to deploy to the GKE cluster.
 Now we need to configure the GitLab agent for Kubernetes for us to be able to use it to deploy the application project.
 
 1. Go to the project [we created to manage the cluster](#create-a-kubernetes-cluster).
-1. Navigate to the [agent configuration file](../../../user/clusters/agent/install/index.md#create-an-agent-configuration-file) (`.gitlab/agents/gke-agent/config.yaml`) and edit it.
+1. Navigate to the [agent configuration file](../../../user/clusters/agent/install/index.md#create-an-agent-configuration-file) (`.gitlab/agents/<agent-name>/config.yaml`) and edit it.
 1. Configure `ci_access:projects` attribute. Use application's project path as `id`:
 
 ```yaml
@@ -127,7 +127,7 @@ Follow these steps to configure the base domain and other settings required for
 1. On the left sidebar, select **Settings > CI/CD** and expand **Variables**.
    - Add a key called `KUBE_INGRESS_BASE_DOMAIN` with the application deployment domain as the value. For this example, use the domain `<IP address>.nip.io`.
    - Add a key called `KUBE_NAMESPACE` with a value of the Kubernetes namespace for your deployments to target. You can use different namespaces per environment. Configure the environment, use the environment scope.
-   - Add a key called `KUBE_CONTEXT` with a value like `path/to/agent/project:gke-agent`. Select the environment scope of your choice.
+   - Add a key called `KUBE_CONTEXT` with the value `<path/to/agent/project>:<agent-name>`. Select the environment scope of your choice.
    - Select **Save changes**.
 
 ## Enable Auto DevOps and run the pipeline
@@ -182,8 +182,6 @@ The jobs are separated into stages:
   - Jobs suffixed with `-sast` run static analysis on the current code to check for potential
     security issues, and are allowed to fail ([Auto SAST](../stages.md#auto-sast))
   - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](../stages.md#auto-secret-detection))
-  - The `license_scanning` job is deprecated and does not produce any results. It is allowed to fail
-    ([Auto License Compliance](../stages.md#auto-license-compliance-deprecated))
 
 - **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
   For more information, see [Dynamic Application Security Testing (DAST)](../../../user/application_security/dast/index.md).
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index 2e6672e3ab0..630123510a9 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Customize Auto DevOps **(FREE ALL)**
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 4191ba257ca..0413ec32283 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Auto DevOps **(FREE ALL)**
@@ -37,7 +37,6 @@ Auto DevOps supports development during each of the [DevOps stages](stages.md).
 | Test | [Auto Code Intelligence](stages.md#auto-code-intelligence) |
 | Test | [Auto Code Quality](stages.md#auto-code-quality) |
 | Test | [Auto Container Scanning](stages.md#auto-container-scanning) |
-| Test | [Auto License Compliance](stages.md#auto-license-compliance-deprecated) |
 | Deploy | [Auto Review Apps](stages.md#auto-review-apps) |
 | Deploy | [Auto Deploy](stages.md#auto-deploy) |
 | Secure | [Auto Dynamic Application Security Testing (DAST)](stages.md#auto-dast) |
@@ -164,8 +163,7 @@ Prerequisites:
 
 To enable Auto DevOps for your instance:
 
-1. On the left sidebar, select **Search or go to**.
-1. Select **Admin Area**.
+1. On the left sidebar, at the bottom, select **Admin Area**.
 1. Select **Settings > CI/CD**.
 1. Expand **Auto DevOps**.
 1. Select the **Default to Auto DevOps pipeline** checkbox.
@@ -207,7 +205,7 @@ match your new GitLab version:
 
 There is no guarantee that you can use a private container registry with Auto DevOps.
 
-Instead, use the [GitLab Container Registry](../../user/packages/container_registry/index.md) with Auto DevOps to
+Instead, use the [GitLab container registry](../../user/packages/container_registry/index.md) with Auto DevOps to
 simplify configuration and prevent any unforeseen issues.
 
 ## Install applications behind a proxy
@@ -220,7 +218,7 @@ installation pods at runtime.
 
 ## Related topics
 
-- [Continuous methodologies](../../ci/introduction/index.md)
+- [Continuous methodologies](../../ci/index.md)
 - [Docker](https://docs.docker.com)
 - [GitLab Runner](https://docs.gitlab.com/runner/)
 - [Helm](https://helm.sh/docs/)
diff --git a/doc/topics/autodevops/multiple_clusters_auto_devops.md b/doc/topics/autodevops/multiple_clusters_auto_devops.md
index 2cb748ab2e9..dbdabae90d9 100644
--- a/doc/topics/autodevops/multiple_clusters_auto_devops.md
+++ b/doc/topics/autodevops/multiple_clusters_auto_devops.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Multiple Kubernetes clusters for Auto DevOps **(FREE ALL)**
diff --git a/doc/topics/autodevops/prepare_deployment.md b/doc/topics/autodevops/prepare_deployment.md
index 1dced373461..da33d6d8761 100644
--- a/doc/topics/autodevops/prepare_deployment.md
+++ b/doc/topics/autodevops/prepare_deployment.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Prepare Auto DevOps for deployment **(FREE ALL)**
@@ -12,10 +12,8 @@ recommend that you prepare them before enabling Auto DevOps.
 
 ## Deployment strategy
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
-
 When using Auto DevOps to deploy your applications, choose the
-[continuous deployment strategy](../../ci/introduction/index.md)
+[continuous deployment strategy](../../ci/index.md)
 that works best for your needs:
 
 | Deployment strategy | Setup | Methodology |
diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md
index a0aaba99a59..1b9c1b0cb9e 100644
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Requirements for Auto DevOps **(FREE ALL)**
@@ -30,7 +30,7 @@ To prepare the deployment:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
 
 When using Auto DevOps to deploy your applications, choose the
-[continuous deployment strategy](../../ci/introduction/index.md)
+[continuous deployment strategy](../../ci/index.md)
 that works best for your needs:
 
 | Deployment strategy | Setup | Methodology |
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index ec587dfc974..541dfbe04fa 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Stages of Auto DevOps **(FREE ALL)**
@@ -240,18 +240,6 @@ check out. The merge request widget displays any security warnings detected,
 For more information, see
 [Dependency Scanning](../../user/application_security/dependency_scanning/index.md).
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-
-## Auto License Compliance (deprecated) **(ULTIMATE ALL)**
-
-This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387561) in GitLab 15.9,
-in GitLab 16.3 we [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/421363) support for the License Compliance report.
-Auto License Compliance is still present in the pipeline, but won't produce any results.
-
-Use Auto Dependency Scanning instead.
-
-<!--- end_remove -->
-
 ## Auto Container Scanning
 
 Vulnerability static analysis for containers uses [Trivy](https://aquasecurity.github.io/trivy/latest/)
diff --git a/doc/topics/autodevops/troubleshooting.md b/doc/topics/autodevops/troubleshooting.md
index 11b5265b9a3..bff21c19165 100644
--- a/doc/topics/autodevops/troubleshooting.md
+++ b/doc/topics/autodevops/troubleshooting.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Troubleshooting Auto DevOps **(FREE ALL)**
diff --git a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
index dc18f863844..3a58d493657 100644
--- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
+++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
@@ -1,8 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
-type: reference
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Upgrading deployments for newer Auto Deploy dependencies **(FREE ALL)**
diff --git a/doc/topics/autodevops/upgrading_postgresql.md b/doc/topics/autodevops/upgrading_postgresql.md
index d2410da76aa..9daddfbe7c5 100644
--- a/doc/topics/autodevops/upgrading_postgresql.md
+++ b/doc/topics/autodevops/upgrading_postgresql.md
@@ -1,7 +1,7 @@
 ---
 stage: Deploy
 group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Upgrading PostgreSQL for Auto DevOps **(FREE ALL)**
diff --git a/doc/topics/build_your_application.md b/doc/topics/build_your_application.md
index 02335c77b73..430ef9ec57d 100644
--- a/doc/topics/build_your_application.md
+++ b/doc/topics/build_your_application.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Use CI/CD to build your application **(FREE ALL)**
diff --git a/doc/topics/cron/index.md b/doc/topics/cron/index.md
index ca1bc7f40f2..057ae82e6ad 100644
--- a/doc/topics/cron/index.md
+++ b/doc/topics/cron/index.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Cron
@@ -38,7 +38,7 @@ are valid:
 - Run once a day at midnight: `0 0 * * *`
 - Run once a week at midnight on Sunday morning: `0 0 * * 0`
 - Run once a month at midnight of the first day of the month: `0 0 1 * *`
-- Run once a month on the 22nd: `0 0 22 * *`)
+- Run once a month on the 22nd: `0 0 22 * *`
 - Run once a month on the 2nd Monday: `0 0 * * 1#2`
 - Run once a year at midnight of 1 January: `0 0 1 1 *`
 - Run every other Sunday at 0900 hours: `0 9 * * sun%2`
diff --git a/doc/topics/git/cherry_picking.md b/doc/topics/git/cherry_picking.md
index 7f0da5a594e..fe7bd333f88 100644
--- a/doc/topics/git/cherry_picking.md
+++ b/doc/topics/git/cherry_picking.md
@@ -1,7 +1,7 @@
 ---
 stage: Create
 group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Cherry-pick a Git commit **(FREE ALL)**
diff --git a/doc/topics/git/get_started.md b/doc/topics/git/get_started.md
new file mode 100644
index 00000000000..c2738f9e748
--- /dev/null
+++ b/doc/topics/git/get_started.md
@@ -0,0 +1,85 @@
+---
+stage: Create
+group: Source Code
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Get started with Git
+
+You can use Git from a command line to interact with GitLab.
+
+## Common terms
+
+If you're new to Git, start by reviewing some of the most commonly used terms.
+
+### Repository
+
+Files are stored in a **repository**. A repository is similar to how you
+store files in a folder or directory on your computer.
+
+- A **remote repository** refers to the files in GitLab.
+- A **local copy** refers to the files on your computer.
+
+The word **repository** is often shortened to **repo**.
+
+In GitLab, a repository is part of a **project**.
+
+**Get started:**
+
+- [Learn more about repositories](../../user/project/repository/index.md).
+- [Tutorial: Make your first Git commit](../../tutorials/make_first_git_commit/index.md).
+
+### Clone
+
+To create a copy of a remote repository's files on your computer, you **clone** it.
+When you clone a repository, you can sync the repository with the remote repository in GitLab.
+You can modify the files locally and upload the changes to the remote repository on GitLab.
+
+**Get started:**
+
+- [Clone a repository from GitLab to your local machine](../../gitlab-basics/start-using-git.md#clone-a-repository).
+
+### Pull
+
+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 action is known as **pulling** from the remote, because you use the command `git pull`.
+
+**Get started**:
+
+- [Download the latest changes in the project](../../gitlab-basics/start-using-git.md#download-the-latest-changes-in-the-project).
+
+### 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 action is known as **pushing** to the remote, because you use the command
+`git push`.
+
+**Get started**:
+
+- [Send changes to GitLab](../../gitlab-basics/start-using-git.md#send-changes-to-gitlab).
+
+### Fork
+
+When you want to contribute to someone else's repository, you make a copy of it.
+This copy is called a **fork**.
+
+When you create a fork of a repository, you create a copy of the project in your own
+namespace in the remote repository.
+You then have write permissions to modify the project files and settings.
+
+For example, you can fork this project in to your namespace:
+
+- <https://gitlab.com/gitlab-tests/sample-project/>
+
+You now have your own copy of the repository. You can view the namespace in the URL, for example:
+
+- `https://gitlab.com/your-namespace/sample-project/`
+
+Then you can clone the repository to your local machine, work on the files, and submit changes back to the
+original repository.
+
+**Get started**
+
+- [Learn more about forks](../../user/project/repository/forking_workflow.md).
+- [Learn more about namespaces](../../user/namespace/index.md).
diff --git a/doc/topics/git/git_add.md b/doc/topics/git/git_add.md
index db85e75a6a8..5d4c38bf320 100644
--- a/doc/topics/git/git_add.md
+++ b/doc/topics/git/git_add.md
@@ -1,39 +1,11 @@
 ---
-stage: Create
-group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../../gitlab-basics/add-file.md'
+remove_date: '2024-02-03'
 ---
 
-# Git add **(FREE ALL)**
+This document was moved to [another location](../../gitlab-basics/add-file.md).
 
-Adds content to the index or staging area.
-
-- Adds a list of file:
-
-  ```shell
-  git add <files>
-  ```
-
-- Adds all files including deleted ones:
-
-  ```shell
-  git add -A
-  ```
-
-- Add all text files in current dir:
-
-  ```shell
-  git add *.txt
-  ```
-
-- Add all text file in the project:
-
-  ```shell
-  git add "*.txt*"
-  ```
-
-- Adds all files in directory:
-
-  ```shell
-  git add views/layouts/
-  ```
+<!-- This redirect file can be deleted after <2024-02-03>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md
index 78275746de5..63ac1d845e0 100644
--- a/doc/topics/git/git_rebase.md
+++ b/doc/topics/git/git_rebase.md
@@ -1,102 +1,113 @@
 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
-type: concepts, howto
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 description: "Introduction to Git rebase and force push, methods to resolve merge conflicts through the command line."
 ---
 
 # Git rebase and force push **(FREE ALL)**
 
-This guide helps you to get started with rebases, force pushes, and fixing
-[merge conflicts](../../user/project/merge_requests/conflicts.md) locally.
-Before you attempt a force push or a rebase, make sure you are familiar with
-[Git through the command line](../../gitlab-basics/start-using-git.md).
+In Git, a rebase updates your branch with the contents of another branch.
+A rebase confirms that changes in your branch don't conflict with
+changes in the target branch.
 
-WARNING:
-`git rebase` rewrites the commit history. It **can be harmful** to do it in
-shared branches. It can cause complex and hard to resolve
-[merge conflicts](../../user/project/merge_requests/conflicts.md). In
-these cases, instead of rebasing your branch against the default branch,
-consider pulling it instead (`git pull origin master`). Pulling has similar
-effects with less risk compromising the work of your contributors.
+If you have a [merge conflict](../../user/project/merge_requests/conflicts.md),
+you can rebase to fix it.
 
-In Git, a rebase updates your feature branch with the contents of another branch.
-This step is important for Git-based development strategies. Use a rebase to confirm
-that your branch's changes don't conflict with any changes added to your target branch
-_after_ you created your feature branch.
+## What happens during rebase
 
 When you rebase:
 
-1. Git imports all the commits submitted to your target branch _after_ you initially created
-   your feature branch from it.
-1. Git stacks the commits you have in your feature branch on top of all
+1. Git imports all the commits submitted to your target branch after you initially created
+   your branch from it.
+1. Git stacks the commits you have in your branch on top of all
    the commits it imported from that branch:
 
-![Git rebase illustration](img/git_rebase_v13_5.png)
+   ![Git rebase illustration](img/git_rebase_v13_5.png)
 
 While most rebases are performed against `main`, you can rebase against any other
 branch, such as `release-15-3`. You can also specify a different remote repository
 (such as `upstream`) instead of `origin`.
 
-## Back up a branch before rebase
+WARNING:
+`git rebase` rewrites the commit history. It **can be harmful** to do it in
+shared branches. It can cause complex and hard to resolve
+merge conflicts. Instead of rebasing your branch against the default branch,
+consider pulling it instead (`git pull origin master`). Pulling has similar
+effects with less risk of compromising others' work.
 
-To back up a branch before taking any destructive action, like a rebase or force push:
+## Rebase by using Git
 
-1. Open your feature branch in the terminal: `git checkout my-feature`
-1. Create a backup branch: `git branch my-feature-backup`
-   Any changes added to `my-feature` after this point are lost
-   if you restore from the backup branch.
+When you use Git to rebase, each commit is applied to your branch.
+When merge conflicts occur, you are prompted to address them.
 
-Your branch is backed up, and you can try a rebase or a force push.
-If anything goes wrong, restore your branch from its backup:
+If you want more advanced options for your commits,
+do [an interactive rebase](#rebase-interactively-by-using-git).
 
-1. Make sure you're in the correct branch (`my-feature`): `git checkout my-feature`
-1. Reset it against `my-feature-backup`: `git reset --hard my-feature-backup`
+Prerequisites:
 
-## Rebase a branch
+- You must have permission to force push to branches.
 
-[Rebases](https://git-scm.com/docs/git-rebase) are very common operations in
-Git, and have these options:
+To use Git to rebase your branch against the target branch:
 
-- **Regular rebases.** This type of rebase can be done through the
-  [command line](#regular-rebase) and [the GitLab UI](#from-the-gitlab-ui).
-- [**Interactive rebases**](#interactive-rebase) give more flexibility by
-  enabling you to specify how to handle each commit. Interactive rebases
-  must be done on the command line.
+1. Open a terminal and change to your project.
+1. Ensure you have the latest contents of the target branch.
+   In this example, the target branch is `main`:
 
-Any user who rebases a branch is treated as having added commits to that branch.
-If a project is configured to
-[**prevent approvals by users who add commits**](../../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits),
-a user who rebases a branch cannot also approve its merge request.
+   ```shell
+   git fetch origin main
+   ```
 
-### Regular rebase
+1. Check out your branch:
 
-Standard rebases replay the previous commits on a branch without changes, stopping
-only if merge conflicts occur.
+   ```shell
+   git checkout my-branch
+   ```
 
-Prerequisites:
+1. Optional. Create a backup of your branch:
 
-- You must have permission to force push branches.
+   ```shell
+   git branch my-branch-backup
+   ```
 
-To update your branch `my-feature` with recent changes from your
-[default branch](../../user/project/repository/branches/default.md) (here, using `main`):
+   Changes added to `my-branch` after this point are lost
+   if you restore from the backup branch.
 
-1. Fetch the latest changes from `main`: `git fetch origin main`
-1. Check out your feature branch: `git checkout my-feature`
-1. Rebase it against `main`: `git rebase origin/main`
-1. [Force push](#force-push) to your branch.
+1. Rebase against the main branch:
 
-If there are merge conflicts, Git prompts you to fix them before continuing the rebase.
+   ```shell
+   git rebase origin/main
+   ```
 
-### From the GitLab UI
+1. If merge conflicts exist:
+   1. Fix the conflicts in your editor.
 
-The `/rebase` [quick action](../../user/project/quick_actions.md#issues-merge-requests-and-epics)
-rebases your feature branch directly from its merge request if all of these
-conditions are met:
+   1. Add the files:
 
-- No merge conflicts exist for your feature branch.
-- You have the **Developer** role for the source project. This role grants you
+      ```shell
+      git add .
+      ```
+
+   1. Continue the rebase:
+
+      ```shell
+      git rebase --continue
+      ```
+
+1. Force push your changes to the target branch, while protecting others' commits:
+
+   ```shell
+   git push origin my-branch --force-with-lease
+   ```
+
+## Rebase from the UI
+
+You can rebase a merge request from the GitLab UI.
+
+Prerequisites:
+
+- No merge conflicts must exist.
+- You must have at least the **Developer** role for the source project. This role grants you
   permission to push to the source branch for the source project.
 - If the merge request is in a fork, the fork must allow commits
   [from members of the upstream project](../../user/project/merge_requests/allow_collaboration.md).
@@ -107,91 +118,112 @@ To rebase from the UI:
 1. Type `/rebase` in a comment.
 1. Select **Comment**.
 
-GitLab schedules a rebase of the feature branch against the default branch and
+GitLab schedules a rebase of the branch against the default branch and
 executes it as soon as possible.
 
-### Interactive rebase
-
-Use an interactive rebase (the `--interactive` flag, or `-i`) to simultaneously
-update a branch while you modify how its commits are handled.
-For example, to edit the last five commits in your branch (`HEAD~5`), run:
-
-```shell
-git rebase -i HEAD~5
-```
-
-Git opens the last five commits in your terminal text editor, oldest commit first.
-Each commit shows the action to take on it, the SHA, and the commit title:
-
-```shell
-pick 111111111111 Second round of structural revisions
-pick 222222222222 Update inbound link to this changed page
-pick 333333333333 Shifts from H4 to H3
-pick 444444444444 Adds revisions from editorial
-pick 555555555555 Revisions continue to build the concept part out
-
-# Rebase 111111111111..222222222222 onto zzzzzzzzzzzz (5 commands)
-#
-# Commands:
-# p, pick <commit> = use commit
-# r, reword <commit> = use commit, but edit the commit message
-# e, edit <commit> = use commit, but stop for amending
-# s, squash <commit> = use commit, but meld into previous commit
-# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
-```
-
-After the list of commits, a commented-out section shows some common actions you
-can take on a commit:
-
-- **Pick** a commit to use it with no changes. The default option.
-- **Reword** a commit message.
-- **Edit** a commit to use it, but pause the rebase to amend (add changes to) it.
-- **Squash** multiple commits together to simplify the commit history
-  of your feature branch.
-
-Replace the keyword `pick` according to
-the operation you want to perform in each commit. To do so, edit
-the commits in your terminal's text editor.
-
-For example, with [Vim](https://www.vim.org/) as the text editor in
-a macOS Zsh shell, you can `squash` or `fixup` (combine) all of the commits together:
-
-NOTE:
-The steps for editing through the command line can be slightly
-different depending on your operating system and the shell you use.
-
-1. Press <kbd>i</kbd> on your keyboard to switch to Vim's editing mode.
-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 remaining commits.
-   Leave the first commit **unchanged** (`pick`) as we want to squash
-   all other commits into it.
-1. Press <kbd>Escape</kbd> to leave the editing mode.
-1. Type `:wq` to "write" (save) and "quit".
+## Rebase interactively by using Git
+
+Use an interactive rebase when you want to specify how to handle each commit.
+You must do an interactive rebase from the command line.
+
+Prerequisites:
+
+- [Vim](https://www.vim.org/) must be your text editor to follow these instructions.
+
+To rebase interactively:
+
+1. Open a terminal and change to your project.
+1. Ensure you have the latest contents of the target branch.
+   In this example, the target branch is `main`:
+
+   ```shell
+   git fetch origin main
+   ```
+
+1. Check out your branch:
+
+   ```shell
+   git checkout my-branch
+   ```
+
+1. Optional. Create a backup of your branch:
+
+   ```shell
+   git branch my-branch-backup
+   ```
+
+   Changes added to `my-branch` after this point are lost
+   if you restore from the backup branch.
+
+1. In the GitLab UI, in your merge request, confirm how many commits
+   you want to rebase by viewing the **Commits** tab.
+
+1. Open these commits. For example, to edit the last five commits in your branch (`HEAD~5`), type:
+
+   ```shell
+   git rebase -i HEAD~5
+   ```
+
+   Git opens the last five commits in your terminal text editor, oldest commit first.
+   Each commit shows the action to take on it, the SHA, and the commit title:
+
+   ```shell
+   pick 111111111111 Second round of structural revisions
+   pick 222222222222 Update inbound link to this changed page
+   pick 333333333333 Shifts from H4 to H3
+   pick 444444444444 Adds revisions from editorial
+   pick 555555555555 Revisions continue to build the concept part out
+
+   # Rebase 111111111111..222222222222 onto zzzzzzzzzzzz (5 commands)
+   #
+   # Commands:
+   # p, pick <commit> = use commit
+   # r, reword <commit> = use commit, but edit the commit message
+   # e, edit <commit> = use commit, but stop for amending
+   # s, squash <commit> = use commit, but meld into previous commit
+   # f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
+   ```
+
+1. Switch to Vim's edit mode by pressing <kbd>i</kbd>.
+1. Move to the second commit in the list by using your keyboard arrows.
+1. Change the word `pick` to `squash` or `fixup` (or `s` or `f`).
+1. Do the same for the remaining commits. Leave the first commit as `pick`.
+1. End edit mode, save, and quit:
+
+   - Press <kbd>ESC</kbd>.
+   - Type `:wq`.
+
 1. When squashing, Git outputs the commit message so you have a chance to edit it:
+
    - All lines starting with `#` are ignored and not included in the commit
-   message. Everything else is included.
-   - To leave it as it is, type `:wq`. To edit the commit message: switch to the
-   editing mode, edit the commit message, and save it as you just did.
-1. If you haven't pushed your commits to the remote branch before rebasing,
-   push your changes without a force push. If you had pushed these commits already,
-   [force push](#force-push) instead.
+     message. Everything else is included.
+   - To leave it as-is, type `:wq`. To edit the commit message, switch to
+     edit mode, edit the commit message, and save.
+
+1. Commit to the target branch.
 
-#### Configure squash options for a project
+   - If you didn't push your commits to the target branch before rebasing,
+     push your changes without a force push:
 
-Keeping the default branch commit history clean doesn't require you to
-manually squash all your commits on each merge request. GitLab provides
-[squash and merge](../../user/project/merge_requests/squash_and_merge.md#configure-squash-options-for-a-project),
-options at a project level.
+     ```shell
+     git push origin my-branch
+     ```
 
-## Force push
+   - If you pushed these commits already, use a force push:
+
+     ```shell
+     git push origin my-branch --force-with-lease
+     ```
+
+## Force pushing
 
 Complex operations in Git require you to force an update to the remote branch.
 Operations like squashing commits, resetting a branch, or rebasing a branch rewrite
 the history of your branch. Git requires a forced update to help safeguard against
 these more destructive changes from happening accidentally.
 
-Force pushing is not recommended on shared branches, as you risk destroying the
-changes of others.
+Force pushing is not recommended on shared branches, because you risk destroying
+others' changes.
 
 If the branch you want to force push is [protected](../../user/project/protected_branches.md),
 you can't force push to it unless you either:
@@ -202,27 +234,32 @@ you can't force push to it unless you either:
 
 Then you can force push and protect it again.
 
-### `--force-with-lease` flag
+## Restore your backed up branch
+
+Your branch is backed up, and you can try a rebase or a force push.
+If anything goes wrong, restore your branch from its backup:
+
+1. Make sure you're in the correct branch:
 
-The [`--force-with-lease`](https://git-scm.com/docs/git-push#Documentation/git-push.txt---force-with-leaseltrefnamegt)
-flag force pushes. Because it preserves any new commits added to the remote
-branch by other people, it is safer than `--force`:
+   ```shell
+   git checkout my-branch
+   ```
 
-```shell
-git push --force-with-lease origin my-feature
-```
+1. Reset your branch against the backup:
 
-### `--force` flag
+   ```shell
+   git reset --hard my-branch-backup
+   ```
 
-The `--force` flag forces pushes, but does not preserve any new commits added to
-the remote branch by other people. To use this method, pass the flag `--force` or `-f`
-to the `push` command:
+## Approving after rebase
 
-```shell
-git push --force origin my-feature
-```
+If you rebase a branch, you've added commits.
+If your project is configured to
+[prevent approvals by users who add commits](../../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits),
+you can't approve a merge request if you have rebased it.
 
 ## Related topics
 
 - [Numerous undo possibilities in Git](numerous_undo_possibilities_in_git/index.md#undo-staged-local-changes-without-modifying-history)
 - [Git documentation for branches and rebases](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
+- [Project squash and merge settings](../../user/project/merge_requests/squash_and_merge.md#configure-squash-options-for-a-project)
diff --git a/doc/topics/git/how_to_install_git/index.md b/doc/topics/git/how_to_install_git/index.md
index 52e8e2e1259..5a93f0fcd69 100644
--- a/doc/topics/git/how_to_install_git/index.md
+++ b/doc/topics/git/how_to_install_git/index.md
@@ -1,79 +1,52 @@
 ---
 stage: Create
 group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
-description: 'This article describes how to install Git on macOS, Ubuntu Linux and Windows.'
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Installing Git **(FREE ALL)**
 
-To begin contributing to GitLab projects, you must install the appropriate Git client
-on your computer. Information about [installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-is also available at the official Git website.
+To begin contributing to GitLab projects, you must download and install the Git client on your computer.
 
-## Supported operating systems
+This page provides information on installing Git on the following operating systems:
 
-Git is available for the following operating systems:
+- macOS
+- Ubuntu Linux
+- Microsoft Windows
 
-- [macOS](#macos)
-- [Ubuntu Linux](#ubuntu-linux)
-- [Microsoft Windows](#windows)
+For information on downloading and installing Git on other operating systems, see the
+[official Git website](https://git-scm.com/downloads).
 
-### macOS
+## Install and update Git on macOS
 
-A version of Git is supplied by macOS. You can use this version, or install the latest
-version of Git on macOS by downloading it from the project website. We recommend
-installing Git with [Homebrew](https://brew.sh/index.html). With Homebrew, you can
-access an extensive selection of libraries and applications, with their dependencies
-managed for you.
+Though a version of Git is supplied by macOS, you should install the latest version of Git. A common way to
+install Git is with [Homebrew](https://brew.sh/index.html).
 
-Prerequisites:
+To install the latest version of Git on macOS with Homebrew:
 
-- 15 GB of available disk space for Homebrew and Xcode.
-- Extra disk space for any additional development libraries.
-
-To install Git on macOS:
-
-1. Open a terminal and install Xcode Command Line Tools:
-
-   ```shell
-   xcode-select --install
-   ```
-
-   Alternatively, you can install the entire [Xcode](https://developer.apple.com/xcode/)
-   package through the macOS App Store.
-
-1. Select **Install** to download and install Xcode Command Line Tools.
-1. Install Homebrew according to the [official Homebrew installation instructions](https://brew.sh/index.html).
-1. Install Git by running `brew install git` from your terminal.
-1. In a terminal, verify that Git works on your computer:
+1. If you've never installed Homebrew before, follow the
+   [Homebrew installation instructions](https://brew.sh/index.html).
+1. In a terminal, install Git by running `brew install git`.
+1. Verify that Git works on your computer:
 
    ```shell
    git --version
    ```
 
-#### macOS update
-
-Periodically you may need to update the version of Git installed by
-[Homebrew](/ee/topics/git/how_to_install_git/index.md#macos). To do so,
-open a terminal and run these commands:
+Keep Git up to date by periodically running the following command:
 
 ```shell
-brew update
-brew upgrade git
+brew update && brew upgrade git
 ```
 
-To verify you are on the updated version, run `git --version` to display
-your current version of Git.
+## Install and update Git on Ubuntu Linux
 
-### Ubuntu Linux
+Though a version of Git is supplied by Ubuntu, you should install the latest version of Git. The latest version is
+available using a Personal Package Archive (PPA).
 
-On Ubuntu and other Linux operating systems, use the built-in package manager
-to install Git:
+To install the latest version of Git on Ubuntu Linux with a PPA:
 
-1. Open a terminal and run these commands to install the latest Git
-from the officially
-   maintained package archives:
+1. In a terminal, configure the required PPA, update the list of Ubuntu packages, and install `git`:
 
    ```shell
    sudo apt-add-repository ppa:git-core/ppa
@@ -81,32 +54,23 @@ from the officially
    sudo apt-get install git
    ```
 
-1. To verify that Git works on your computer, run:
+1. Verify that Git works on your computer:
 
    ```shell
    git --version
    ```
 
-#### Ubuntu Linux Update
+Keep Git up to date by periodically running the following command:
 
-Periodically it may be necessary to update Git installed. To do so, run the same [commands](/ee/topics/git/how_to_install_git/index.md#ubuntu-linux).
+```shell
+sudo apt-get update && sudo apt-get install git
+```
 
-### Windows
+## Install Git on Microsoft Windows
 
-Go to the [Git website](https://git-scm.com/), and then download and install Git for Windows.
+For information on downloading and installing Git on Microsoft Windows, see the
+[official Git documentation](https://git-scm.com/download/win).
 
 ## After you install Git
 
 After you successfully install Git on your computer, read about [adding an SSH key to GitLab](../../../user/ssh.md).
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, for example `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/topics/git/index.md b/doc/topics/git/index.md
index e349cf0bb92..c7b1832c8b8 100644
--- a/doc/topics/git/index.md
+++ b/doc/topics/git/index.md
@@ -1,8 +1,7 @@
 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
-type: index
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
 # Git **(FREE ALL)**
@@ -38,7 +37,7 @@ appropriate for when you're ready to start learning Git by doing:
 - [How to install Git](how_to_install_git/index.md)
 - [Start using Git on the command line](../../gitlab-basics/start-using-git.md)
 - Tutorial: [Make your first Git commit](../../tutorials/make_first_git_commit/index.md)
-- Tutorial: [How to update Git commit messages](../../tutorials/update_commit_messages/index.md)
+- Tutorial: [Update Git commit messages](../../tutorials/update_commit_messages/index.md)
 - The [GitLab CLI](https://gitlab.com/gitlab-org/cli/)
 
 A typical Git user encounters these concepts soon after starting to use Git:
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index 23d972e9aa7..fb2aa8df6b7 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -1,8 +1,7 @@
 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
-type: reference, howto
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
 # Git Large File Storage (LFS) **(FREE ALL)**
@@ -51,7 +50,7 @@ your operating system. GitLab requires version 1.0.1 or later of the Git LFS cli
 - Any Git LFS request asks for HTTPS credentials, so we recommend a good Git
   credentials store.
 - Git LFS always assumes HTTPS so if you have GitLab server on HTTP you must
-  [add the URL to Git configuration manually](#troubleshooting).
+  [add the URL to Git configuration manually](troubleshooting.md#getsockopt-connection-refused).
 - [Group wikis](../../../user/project/wiki/group.md) do not support Git LFS.
 
 ## How LFS objects affect repository size
@@ -164,158 +163,4 @@ Technical details about how this works can be found in the [development document
 - Blog post: [Getting started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
 - [Git LFS developer information](../../../development/lfs.md)
 - [GitLab Git Large File Storage (LFS) Administration](../../../administration/lfs/index.md) for self-managed instances
-
-## Troubleshooting
-
-### Encountered `n` files that should have been pointers, but weren't
-
-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)
-
-To resolve the problem, migrate the affected file (or files) and push back to the repository:
-
-1. Migrate the file to LFS:
-
-   ```shell
-   git lfs migrate import --yes --no-rewrite "<your-file>"
-   ```
-
-1. Push back to your repository:
-
-   ```shell
-   git push
-   ```
-
-1. Optional. Clean up your `.git` folder:
-
-   ```shell
-   git reflog expire --expire-unreachable=now --all
-   git gc --prune=now
-   ```
-
-### error: Repository or object not found
-
-This error can occur for a few reasons, including:
-
-- You don't have permissions to access certain LFS object
-
-Check if you have permissions to push to the project or fetch from the project.
-
-- Project is not allowed to access the LFS object
-
-LFS object you are trying to push to the project or fetch from the project is not
-available to the project anymore. Probably the object was removed from the server.
-
-- Local Git repository is using deprecated LFS API
-
-### Invalid status for `<url>` : 501
-
-Git LFS logs the failures into a log file.
-To view this log file, while in project directory:
-
-```shell
-git lfs logs last
-```
-
-If the status `error 501` is shown, it is because:
-
-- Git LFS is not enabled in project settings. Check your project settings and
-  enable Git LFS.
-
-- Git LFS support is not enabled on the GitLab server. Check with your GitLab
-  administrator why Git LFS is not enabled on the server. See
-  [LFS administration documentation](../../../administration/lfs/index.md) for instructions
-  on how to enable LFS support.
-
-- Git LFS client version is not supported by GitLab server. Check your Git LFS
-  version with `git lfs version`. Check the Git configuration of the project for traces
-  of deprecated API with `git lfs -l`. If `batch = false` is set in the configuration,
-  remove the line and try to update your Git LFS client. Only version 1.0.1 and
-  newer are supported.
-
-### `getsockopt: connection refused`
-
-If you push an LFS object to a project and receive an error like this,
-the LFS client is trying to reach GitLab through HTTPS. However, your GitLab
-instance is being served on HTTP:
-
-```plaintext
-Post <URL>/info/lfs/objects/batch: dial tcp IP: getsockopt: connection refused
-```
-
-This behavior is caused by Git LFS using HTTPS connections by default when a
-`lfsurl` is not set in the Git configuration.
-
-To prevent this from happening, set the LFS URL in project Git configuration:
-
-```shell
-git config --add lfs.url "http://gitlab.example.com/group/my-sample-project.git/info/lfs"
-```
-
-### Credentials are always required when pushing an object
-
-NOTE:
-With 8.12 GitLab added LFS support to SSH. The Git LFS communication
-still goes over HTTP, but now the SSH client passes the correct credentials
-to the Git LFS client. No action is required by the user.
-
-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. For more information, see the [official Git documentation](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:
-
-```shell
-git config --global credential.helper 'cache --timeout=3600'
-```
-
-This remembers the credentials for an hour, after which Git operations
-require re-authentication.
-
-If you are using OS X you can use `osxkeychain` to store and encrypt your credentials.
-For Windows, you can use `wincred` or Microsoft's [Git Credential Manager for Windows](https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases).
-
-More details about various methods of storing the user credentials can be found
-on [Git Credential Storage documentation](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
-
-### LFS objects are missing on push
-
-GitLab checks files to detect LFS pointers on push. If LFS pointers are detected, GitLab tries to verify that those files already exist in LFS on GitLab.
-
-Verify that LFS is installed locally and consider a manual push with `git lfs push --all`.
-
-If you are storing LFS files outside of GitLab you can disable LFS on the project by setting `lfs_enabled: false` with the [projects API](../../../api/projects.md#edit-project).
-
-### Hosting LFS objects externally
-
-It is possible to host LFS objects externally by setting a custom LFS URL with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`.
-
-You might choose to do this if you are using an appliance like a Nexus Repository to store LFS data. If you choose to use an external LFS store,
-GitLab can't verify LFS objects. Pushes then fail if you have GitLab LFS support enabled.
-
-To stop push failure, LFS support can be disabled in the [Project settings](../../../user/project/settings/index.md), which also disables GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS).
-
-### I/O timeout when pushing LFS objects
-
-You might get an error that states:
-
-```shell
-LFS: Put "http://your-instance.com/root/project.git/gitlab-lfs/objects/cc29e205d04a4062d0fb131700e8bfc8e54c44d0176a8dca22f40b24ef26d325/15": read tcp your-instance-ip:54544->your-instance-ip:443: i/o timeout
-error: failed to push some refs to 'ssh://your-instance.com:2222/root/project.git'
-```
-
-When network conditions are unstable, the Git LFS client might time out when trying to upload files
-if network conditions are unstable.
-
-The workaround is to set the client activity timeout a higher value.
-
-For example, to set the timeout to 60 seconds:
-
-```shell
-git config lfs.activitytimeout 60
-```
+- [Troubleshooting Git LFS](troubleshooting.md)
diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md
index d14d0db6087..9887650c5f0 100644
--- a/doc/topics/git/lfs/migrate_to_git_lfs.md
+++ b/doc/topics/git/lfs/migrate_to_git_lfs.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 description: "How to migrate an existing Git repository to Git LFS with BFG."
 ---
 
diff --git a/doc/topics/git/lfs/troubleshooting.md b/doc/topics/git/lfs/troubleshooting.md
new file mode 100644
index 00000000000..63bf6368e79
--- /dev/null
+++ b/doc/topics/git/lfs/troubleshooting.md
@@ -0,0 +1,162 @@
+---
+stage: Create
+group: Source Code
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
+---
+
+# Troubleshooting Git LFS
+
+When working with Git LFS, you might encounter the following issues.
+
+## Encountered `n` files that should have been pointers, but weren't
+
+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)
+
+To resolve the problem, migrate the affected file (or files) and push back to the repository:
+
+1. Migrate the file to LFS:
+
+   ```shell
+   git lfs migrate import --yes --no-rewrite "<your-file>"
+   ```
+
+1. Push back to your repository:
+
+   ```shell
+   git push
+   ```
+
+1. Optional. Clean up your `.git` folder:
+
+   ```shell
+   git reflog expire --expire-unreachable=now --all
+   git gc --prune=now
+   ```
+
+## error: Repository or object not found
+
+This error can occur for a few reasons, including:
+
+- You don't have permissions to access certain LFS object
+
+Check if you have permissions to push to the project or fetch from the project.
+
+- Project is not allowed to access the LFS object
+
+LFS object you are trying to push to the project or fetch from the project is not
+available to the project anymore. Probably the object was removed from the server.
+
+- Local Git repository is using deprecated LFS API
+
+## Invalid status for `<url>` : 501
+
+Git LFS logs the failures into a log file.
+To view this log file, while in project directory:
+
+```shell
+git lfs logs last
+```
+
+If the status `error 501` is shown, it is because:
+
+- Git LFS is not enabled in project settings. Check your project settings and
+  enable Git LFS.
+
+- Git LFS support is not enabled on the GitLab server. Check with your GitLab
+  administrator why Git LFS is not enabled on the server. See
+  [LFS administration documentation](../../../administration/lfs/index.md) for instructions
+  on how to enable LFS support.
+
+- Git LFS client version is not supported by GitLab server. Check your Git LFS
+  version with `git lfs version`. Check the Git configuration of the project for traces
+  of deprecated API with `git lfs -l`. If `batch = false` is set in the configuration,
+  remove the line and try to update your Git LFS client. Only version 1.0.1 and
+  newer are supported.
+
+## `getsockopt: connection refused`
+
+If you push an LFS object to a project and receive an error like this,
+the LFS client is trying to reach GitLab through HTTPS. However, your GitLab
+instance is being served on HTTP:
+
+```plaintext
+Post <URL>/info/lfs/objects/batch: dial tcp IP: getsockopt: connection refused
+```
+
+This behavior is caused by Git LFS using HTTPS connections by default when a
+`lfsurl` is not set in the Git configuration.
+
+To prevent this from happening, set the LFS URL in project Git configuration:
+
+```shell
+git config --add lfs.url "http://gitlab.example.com/group/my-sample-project.git/info/lfs"
+```
+
+## Credentials are always required when pushing an object
+
+NOTE:
+With 8.12 GitLab added LFS support to SSH. The Git LFS communication
+still goes over HTTP, but now the SSH client passes the correct credentials
+to the Git LFS client. No action is required by the user.
+
+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. For more information, see the [official Git documentation](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:
+
+```shell
+git config --global credential.helper 'cache --timeout=3600'
+```
+
+This remembers the credentials for an hour, after which Git operations
+require re-authentication.
+
+If you are using OS X you can use `osxkeychain` to store and encrypt your credentials.
+For Windows, you can use `wincred` or Microsoft's [Git Credential Manager for Windows](https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases).
+
+More details about various methods of storing the user credentials can be found
+on [Git Credential Storage documentation](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
+
+## LFS objects are missing on push
+
+GitLab checks files to detect LFS pointers on push. If LFS pointers are detected, GitLab tries to verify that those files already exist in LFS on GitLab.
+
+Verify that LFS is installed locally and consider a manual push with `git lfs push --all`.
+
+If you are storing LFS files outside of GitLab you can disable LFS on the project by setting `lfs_enabled: false` with the [projects API](../../../api/projects.md#edit-project).
+
+## Hosting LFS objects externally
+
+It is possible to host LFS objects externally by setting a custom LFS URL with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`.
+
+You might choose to do this if you are using an appliance like a Nexus Repository to store LFS data. If you choose to use an external LFS store,
+GitLab can't verify LFS objects. Pushes then fail if you have GitLab LFS support enabled.
+
+To stop push failure, LFS support can be disabled in the [Project settings](../../../user/project/settings/index.md), which also disables GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS).
+
+## I/O timeout when pushing LFS objects
+
+You might get an error that states:
+
+```shell
+LFS: Put "http://your-instance.com/root/project.git/gitlab-lfs/objects/cc29e205d04a4062d0fb131700e8bfc8e54c44d0176a8dca22f40b24ef26d325/15": read tcp your-instance-ip:54544->your-instance-ip:443: i/o timeout
+error: failed to push some refs to 'ssh://your-instance.com:2222/root/project.git'
+```
+
+When network conditions are unstable, the Git LFS client might time out when trying to upload files
+if network conditions are unstable.
+
+The workaround is to set the client activity timeout a higher value.
+
+For example, to set the timeout to 60 seconds:
+
+```shell
+git config lfs.activitytimeout 60
+```
diff --git a/doc/topics/git/numerous_undo_possibilities_in_git/index.md b/doc/topics/git/numerous_undo_possibilities_in_git/index.md
index 8c42a394106..bf0f9f243d0 100644
--- a/doc/topics/git/numerous_undo_possibilities_in_git/index.md
+++ b/doc/topics/git/numerous_undo_possibilities_in_git/index.md
@@ -1,26 +1,12 @@
 ---
 stage: Create
 group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
-type: howto
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Undo options in Git **(FREE ALL)**
 
-[Nothing in Git is deleted](https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery),
-so when you work in Git, you can undo your work.
-
-All version control systems have options for undoing work. However,
-because of the de-centralized nature of Git, these options are multiplied.
-The actions you take are based on the
-[stage of development](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository)
-you are in.
-
-For more information about working with Git and GitLab:
-
-- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>&nbsp;Learn why [North Western Mutual chose GitLab](https://youtu.be/kPNMyxKRRoM) for their enterprise source code management.
-- Learn how to [get started with Git](https://about.gitlab.com/resources/whitepaper-moving-to-git/).
-- For more advanced examples, refer to the [Git book](https://git-scm.com/book/en/v2).
+Git provides options for undoing changes. The method for undoing a change depends on whether the change is unstaged, staged, committed, or pushed.
 
 ## When you can undo changes
 
diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md
index add276ad49d..bc73cc36b96 100644
--- a/doc/topics/git/partial_clone.md
+++ b/doc/topics/git/partial_clone.md
@@ -1,8 +1,7 @@
 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
-type: reference, howto
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
 # Partial clone **(FREE ALL)**
diff --git a/doc/topics/git/rollback_commits.md b/doc/topics/git/rollback_commits.md
index b86b7dbfca5..51be4cb6191 100644
--- a/doc/topics/git/rollback_commits.md
+++ b/doc/topics/git/rollback_commits.md
@@ -1,72 +1,111 @@
 ---
 stage: Create
 group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Roll back commits **(FREE ALL)**
 
-## Undo Commits
+In Git, if you make a mistake, you can undo or roll back your changes.
+For more details, see [Undo options](numerous_undo_possibilities_in_git/index.md).
 
-- Undo last commit putting everything back into the staging area:
+## Undo commits by removing them
+
+- Undo your last commit and put everything back in the staging area:
 
   ```shell
   git reset --soft HEAD^
   ```
 
-- Add files and change message with:
+- Add files and change the commit message:
 
   ```shell
   git commit --amend -m "New Message"
   ```
 
-- Undo last and remove changes:
+- Undo the last change and remove all other changes,
+  if you did not push yet:
 
   ```shell
   git reset --hard HEAD^
   ```
 
-- Same as last one but for two commits back:
+- Undo the last change and remove the last two commits,
+  if you did not push yet:
 
   ```shell
   git reset --hard HEAD^^
   ```
 
-**Don't reset after pushing**
+### Git reset sample workflow
+
+The following is a common Git reset workflow:
+
+1. Edit a file.
+1. Check the status of the branch:
+
+   ```shell
+   git status
+   ```
+
+1. Commit the changes to the branch with a wrong commit message:
+
+   ```shell
+   git commit -am "kjkfjkg"
+   ```
+
+1. Check the Git log:
+
+   ```shell
+   git log
+   ```
+
+1. Amend the commit with the correct commit message:
+
+   ```shell
+   git commit --amend -m "New comment added"
+   ```
+
+1. Check the Git log again:
+
+   ```shell
+   git log
+   ```
+
+1. Soft reset the branch:
+
+   ```shell
+   git reset --soft HEAD^
+   ```
+
+1. Check the Git log again:
+
+   ```shell
+   git log
+   ```
+
+1. Pull updates for the branch from the remote:
+
+   ```shell
+   git pull origin <branch>
+   ```
 
-## Reset Workflow
+1. Push changes for the branch to the remote:
 
-1. Edit file again 'edit_this_file.rb'
-1. Check status
-1. Add and commit with wrong message
-1. Check log
-1. Amend commit
-1. Check log
-1. Soft reset
-1. Check log
-1. Pull for updates
-1. Push changes
+   ```shell
+   git push origin <branch>
+   ```
 
-## Commands
+## Undo commits with a new replacement commit
 
 ```shell
-# Change file edit_this_file.rb
-git status
-git commit -am "kjkfjkg"
-git log
-git commit --amend -m "New comment added"
-git log
-git reset --soft HEAD^
-git log
-git pull origin master
-git push origin master
+git revert <commit-sha>
 ```
 
-## Note
+## The difference between `git revert` and `git reset`
 
-- `git revert` vs `git reset`
-- Reset removes the commit while revert removes the changes but leaves the commit
-- Revert is safer considering we can revert a revert
+- The `git reset` command removes the commit. The `git revert` command removes the changes but leaves the commit.
+- The `git revert` command is safer, because you can revert a revert.
 
 ```shell
 # Changed file
diff --git a/doc/topics/git/stash.md b/doc/topics/git/stash.md
index 84a09385bf6..b8288d32be5 100644
--- a/doc/topics/git/stash.md
+++ b/doc/topics/git/stash.md
@@ -1,13 +1,13 @@
 ---
 stage: Create
 group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Git stash **(FREE ALL)**
 
-We use `git stash` to store our changes when they are not ready to be committed,
-but we must change to a different branch.
+Use `git stash` when you want to change to a different branch, and you
+want to store changes that are not ready to be committed.
 
 - Stash:
 
@@ -27,7 +27,7 @@ but we must change to a different branch.
   git stash apply stash@{3}
   ```
 
-- Every time we save a stash it gets stacked so by using `list` we can see all our
+- Every time you save a stash, it gets stacked. Use `list` to see all of the
   stashes.
 
   ```shell
@@ -36,7 +36,7 @@ but we must change to a different branch.
   git stash list --stat
   ```
 
-- To clean our stack, manually remove them:
+- To clean the stack, manually remove them:
 
   ```shell
   # drop top stash
@@ -47,24 +47,24 @@ but we must change to a different branch.
   git stash clear
   ```
 
-- Apply and drop on one command:
+- Use one command to apply and drop:
 
   ```shell
   git stash pop
   ```
 
-- If we meet conflicts, either reset or commit our changes.
-- Conflicts through `pop` doesn't drop a stash afterwards.
+- If you have conflicts, either reset or commit your changes.
+- Conflicts through `pop` don't drop a stash afterwards.
 
-## Git Stash sample workflow
+## Git stash sample workflow
 
-1. Modify a file
-1. Stage file
-1. Stash it
-1. View our stash list
-1. Confirm no pending changes through status
-1. Apply with pop
-1. View list to confirm changes
+1. Modify a file.
+1. Stage file.
+1. Stash it.
+1. View the stash list.
+1. Confirm no pending changes through `git status`.
+1. Apply with `git stash pop`.
+1. View list to confirm changes.
 
 ```shell
 # Modify edit_this_file.rb file
diff --git a/doc/topics/git/terminology.md b/doc/topics/git/terminology.md
index cef9b7cc35b..788bdd1b8a9 100644
--- a/doc/topics/git/terminology.md
+++ b/doc/topics/git/terminology.md
@@ -1,62 +1,11 @@
 ---
-stage: Create
-group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: 'get_started.md'
+remove_date: '2024-02-03'
 ---
 
-# Git concepts
+This document was moved to [another location](get_started.md).
 
-The following are commonly-used Git concepts.
-
-## Repository
-
-In GitLab, files are stored in a **repository**. A repository is similar to how you
-store files in a folder or directory on your computer.
-
-- A **remote repository** refers to the files in GitLab.
-- A **local copy** refers to the files on your computer.
-
-<!-- vale gitlab.Spelling = NO -->
-<!-- vale gitlab.SubstitutionWarning = NO -->
-Often, the word "repository" is shortened to "repo".
-<!-- vale gitlab.Spelling = YES -->
-<!-- vale gitlab.SubstitutionWarning = YES -->
-
-In GitLab, a repository is contained in a **project**.
-
-## Fork
-
-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#create-a-fork).
-The process is called "creating a fork."
-
-When you fork a repository, you create a copy of the project in your own
-[namespace](../../user/namespace/index.md). You then have write permissions to modify the project files
-and settings.
-
-For example, you can fork this project, <https://gitlab.com/gitlab-tests/sample-project/>, into your namespace.
-You now have your own copy of the repository. You can view the namespace in the URL, for example
-`https://gitlab.com/your-namespace/sample-project/`.
-Then you can clone the repository to your local machine, work on the files, and submit changes back to the
-original repository.
-
-## Difference between download and clone
-
-To create a copy of a remote repository's files on your computer, you can either
-**download** or **clone** the repository. If you download it, you cannot sync the repository with the
-remote repository on GitLab.
-
-[Cloning](../../gitlab-basics/start-using-git.md#clone-a-repository) a repository is the same as downloading, except it preserves the Git connection
-with the remote repository. You can then modify the files locally and
-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 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 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).
+<!-- This redirect file can be deleted after <2024-02-03>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/git/troubleshooting_git.md b/doc/topics/git/troubleshooting_git.md
index d29300d5810..dd3a2efc11b 100644
--- a/doc/topics/git/troubleshooting_git.md
+++ b/doc/topics/git/troubleshooting_git.md
@@ -1,8 +1,7 @@
 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
-type: howto
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
 # Troubleshooting Git **(FREE ALL)**
@@ -11,6 +10,38 @@ Sometimes things don't work the way they should or as you might expect when
 you're using Git. Here are some tips on troubleshooting and resolving issues
 with Git.
 
+## Debugging
+
+When troubleshooting problems with Git, try these debugging techniques.
+
+### Use a custom SSH key for a Git command
+
+```shell
+GIT_SSH_COMMAND="ssh -i ~/.ssh/gitlabadmin" git <command>
+```
+
+### Debug problems with cloning
+
+For Git over SSH:
+
+```shell
+GIT_SSH_COMMAND="ssh -vvv" git clone <git@url>
+```
+
+For Git over HTTPS:
+
+```shell
+GIT_TRACE_PACKET=1 GIT_TRACE=2 GIT_CURL_VERBOSE=1 git clone <url>
+```
+
+### Debug Git with traces
+
+Git includes a complete set of [traces for debugging Git commands](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_debugging), for example:
+
+- `GIT_TRACE_PERFORMANCE=1`: enables tracing of performance data, showing how long each particular `git` invocation takes.
+- `GIT_TRACE_SETUP=1`: enables tracing of what `git` is discovering about the repository and environment it's interacting with.
+- `GIT_TRACE_PACKET=1`: enables packet-level tracing for network operations.
+
 ## Broken pipe errors on `git push`
 
 'Broken pipe' errors can occur when attempting to push to a remote repository.
@@ -337,7 +368,7 @@ details. This second request should succeed, and result in a `200 OK` log entry.
 If a `401` log entry lacks a corresponding `200` log entry, the Git client is likely using either:
 
 - An incorrect password.
-- An expired or revoked token.an incorrect
+- An expired or revoked token.
 
 If not rectified, you could encounter
 [`403` (Forbidden) errors](#403-error-when-performing-git-operations-over-http)
diff --git a/doc/topics/git/unstage.md b/doc/topics/git/unstage.md
index 028f34b2433..95958600fb4 100644
--- a/doc/topics/git/unstage.md
+++ b/doc/topics/git/unstage.md
@@ -1,28 +1,43 @@
 ---
 stage: Create
 group: Source Code
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Unstage a file in Git **(FREE ALL)**
 
 When you _stage_ a file in Git, you instruct Git to track changes to the file in
-preparation for a commit. To instruct Git to disregard changes to a file, and not
+preparation for a commit. To disregard changes to a file, and not
 include it in your next commit, _unstage_ the file.
 
-- To remove files from stage use `reset HEAD`, where HEAD is the last commit of
-  the current branch. This unstages the file but maintains the modifications.
+## Unstage a file
+
+- To remove files from staging, but keep your changes:
 
   ```shell
   git reset HEAD <file>
   ```
 
-- To revert the file back to the state it was in before the changes:
+- To unstage the last three commits:
+
+  ```shell
+  git reset HEAD^3
+  ```
+
+- To unstage changes to a certain file from HEAD:
 
   ```shell
-  git checkout -- <file>
+  git reset <filename>
   ```
 
+After you unstage the file, to revert the file back to the state it was in before the changes:
+
+```shell
+git checkout -- <file>
+```
+
+## Remove a file
+
 - To remove a file from disk and repository, use `git rm`. To remove a directory, use the `-r` flag:
 
   ```shell
diff --git a/doc/topics/git/useful_git_commands.md b/doc/topics/git/useful_git_commands.md
index 305008e2642..a397ec749d0 100644
--- a/doc/topics/git/useful_git_commands.md
+++ b/doc/topics/git/useful_git_commands.md
@@ -1,138 +1,21 @@
 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
-type: reference
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
 # Frequently used Git commands **(FREE ALL)**
 
-The GitLab support team has collected these commands to help you. You may not
-need them frequently.
+The following commands are frequently used.
 
-## Remotes
+## Add another URL to a remote
 
-### Add another URL to a remote, so both remotes get updated on each push
+Add another URL to a remote, so both remotes get updated on each push:
 
 ```shell
 git remote set-url --add <remote_name> <remote_url>
 ```
 
-## Staging and reverting changes
-
-### Remove last commit and leave the changes in unstaged
-
-```shell
-git reset --soft HEAD^
-```
-
-### Unstage a certain number of commits from HEAD
-
-To unstage 3 commits, for example, run:
-
-```shell
-git reset HEAD^3
-```
-
-### Unstage changes to a certain file from HEAD
-
-```shell
-git reset <filename>
-```
-
-### Revert a file to HEAD state and remove changes
-
-To revert changes to a file, you can use either:
-
-- `git checkout <filename>`
-- `git reset --hard <filename>`
-
-### Undo a previous commit by creating a new replacement commit
-
-```shell
-git revert <commit-sha>
-```
-
-### Create a new message for last commit
-
-```shell
-git commit --amend
-```
-
-### Create a new message for older commits
-
-WARNING:
-Changing commit history can disrupt others' work if they have cloned, forked, or have active branches.
-Only amend pushed commits if you're sure it's safe.
-To learn more, see [Git rebase and force push](git_rebase.md).
-
-```shell
-git rebase -i HEAD~n
-```
-
-Replace `n` with the number of commits you want to go back.
-
-This opens your text editor with a list of commits.
-In the editor, replace `pick` with `reword` for each commit you want to change the message:
-
-```shell
-reword 1fc6c95 original commit message
-pick 6b2481b another commit message
-pick 5c1291b another commit message
-```
-
-After saving and closing the file, you can update each message in a new editor window.
-
-After updating your commits, you must push them to the repository.
-As this rewrites history, a force push is required.
-To prevent unintentional overwrites, use `--force-with-lease`:
-
-```shell
-git push --force-with-lease
-```
-
-### Add a file to the last commit
-
-```shell
-git add <filename>
-git commit --amend
-```
-
-Append `--no-edit` to the `commit` command if you do not want to edit the commit
-message.
-
-## Stashing
-
-### Stash changes
-
-```shell
-git stash save
-```
-
-The default behavior of `stash` is to save, so you can also use just:
-
-```shell
-git stash
-```
-
-### Unstash your changes
-
-```shell
-git stash apply
-```
-
-### Discard your stashed changes
-
-```shell
-git stash drop
-```
-
-### Apply and drop your stashed changes
-
-```shell
-git stash pop
-```
-
 ## Refs and Log
 
 ### Use reflog to show the log of reference changes to HEAD
@@ -174,36 +57,6 @@ gitk <file>
 gitk --follow <file>
 ```
 
-## Debugging
-
-### Use a custom SSH key for a Git command
-
-```shell
-GIT_SSH_COMMAND="ssh -i ~/.ssh/gitlabadmin" git <command>
-```
-
-### Debug cloning
-
-With SSH:
-
-```shell
-GIT_SSH_COMMAND="ssh -vvv" git clone <git@url>
-```
-
-With HTTPS:
-
-```shell
-GIT_TRACE_PACKET=1 GIT_TRACE=2 GIT_CURL_VERBOSE=1 git clone <url>
-```
-
-### Debugging with Git embedded traces
-
-Git includes a complete set of [traces for debugging Git commands](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_debugging), for example:
-
-- `GIT_TRACE_PERFORMANCE=1`: enables tracing of performance data, showing how long each particular `git` invocation takes.
-- `GIT_TRACE_SETUP=1`: enables tracing of what `git` is discovering about the repository and environment it's interacting with.
-- `GIT_TRACE_PACKET=1`: enables packet-level tracing for network operations.
-
 ## Rebasing
 
 ### Rebase your branch onto the default
@@ -245,4 +98,4 @@ questions that you know someone might ask.
 
 Each scenario can be a third-level heading, for example `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
\ No newline at end of file
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md
index e9feb75dd5c..5eba213cbd4 100644
--- a/doc/topics/gitlab_flow.md
+++ b/doc/topics/gitlab_flow.md
@@ -1,11 +1,11 @@
 ---
 redirect_to: 'https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/'
-remove_date: '2023-10-27'
+remove_date: '2024-07-27'
 ---
 
 This document was moved to [another location](https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/).
 
-<!-- This redirect file can be deleted after <2023-10-27>. -->
+<!-- This redirect file can be deleted after <2024-07-27>. -->
 <!-- Redirects that point to other docs in the same project expire in three months. -->
 <!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
 <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/topics/manage_code.md b/doc/topics/manage_code.md
index 0f1bfc73b27..5fbdbee7017 100644
--- a/doc/topics/manage_code.md
+++ b/doc/topics/manage_code.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Manage your code **(FREE ALL)**
diff --git a/doc/topics/offline/index.md b/doc/topics/offline/index.md
index 56b523c9c6f..b29a06463ba 100644
--- a/doc/topics/offline/index.md
+++ b/doc/topics/offline/index.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Offline GitLab **(FREE SELF)**
diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md
index 4ff9975b317..b6340d905d4 100644
--- a/doc/topics/offline/quick_start_guide.md
+++ b/doc/topics/offline/quick_start_guide.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Install an offline self-managed GitLab instance **(FREE SELF)**
@@ -98,7 +98,7 @@ Follow these steps to enable SSL for your fresh instance. These steps reflect th
    sudo gitlab-ctl reconfigure
    ```
 
-## Enabling the GitLab Container Registry
+## Enabling the GitLab container registry
 
 Follow these steps to enable the container registry. These steps reflect those for
 [configuring the container registry under an existing domain](../../administration/packages/container_registry.md#configure-container-registry-under-an-existing-gitlab-domain):
diff --git a/doc/topics/plan_and_track.md b/doc/topics/plan_and_track.md
index 2ad46799316..3712d73929c 100644
--- a/doc/topics/plan_and_track.md
+++ b/doc/topics/plan_and_track.md
@@ -1,7 +1,7 @@
 ---
 stage: Plan
 group: Project Management
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Plan and track work **(FREE ALL)**
diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md
index e0580d52765..27c5cc50e5f 100644
--- a/doc/topics/release_your_application.md
+++ b/doc/topics/release_your_application.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Deploy and release your application **(FREE ALL)**
diff --git a/doc/topics/set_up_organization.md b/doc/topics/set_up_organization.md
index a8498ff970c..84d7bb1add0 100644
--- a/doc/topics/set_up_organization.md
+++ b/doc/topics/set_up_organization.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Set up your organization **(FREE ALL)**