Add latest changes from gitlab-org/gitlab@master

16 files changed, 184 insertions, 189 deletions

diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 7a2a136187e..6ec00156021 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -356,7 +356,7 @@ but `LocalAccounts` authenticates against local Active Directory accounts. Befor
   Ensure the payload includes `email` that matches the user's email access.
 - After you enable the custom policy, users might see `Invalid username or password`
   after they try to sign in. This might be a configuration issue with the `IdentityExperienceFramework`
-  app. See [this Microsoft comment](https://learn.microsoft.com/en-us/answers/questions/50355/unable-to-sign-on-using-custom-policy.html?childToView=122370#comment-122370) that suggests you check that the app manifest
+  app. See [this Microsoft comment](https://learn.microsoft.com/en-us/answers/questions/50355/unable-to-sign-on-using-custom-policy?childtoview=122370#comment-122370) that suggests you check that the app manifest
   contains these settings:
 
   - `"accessTokenAcceptedVersion": null`
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 79a3f65377b..912de360e43 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -366,7 +366,7 @@ former is ideal for replicating data belonging to a subset of users, while the
 latter is more suited to progressively rolling out Geo to a large GitLab
 instance.
 
-It is important to note that selective synchronization:
+Selective synchronization:
 
 1. Does not restrict permissions from **secondary** sites.
 1. Does not hide project metadata from **secondary** sites.
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index fe2ef8139ee..9f095c797fb 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -1515,7 +1515,7 @@ Geo::RepositorySyncService.new(project).execute
 
 ### Authorization errors from LFS HTTP(S) client requests
 
-You may have problems if you're running a version of [Git LFS](https://git-lfs.github.com/) before 2.4.2.
+You may have problems if you're running a version of [Git LFS](https://git-lfs.com/) before 2.4.2.
 As noted in [this authentication issue](https://github.com/git-lfs/git-lfs/issues/3025),
 requests redirected from the secondary to the primary site do not properly send the
 Authorization header. This may result in either an infinite `Authorization <-> Redirect`
diff --git a/doc/administration/get_started.md b/doc/administration/get_started.md
index f96d0055bae..ca0408c2ba5 100644
--- a/doc/administration/get_started.md
+++ b/doc/administration/get_started.md
@@ -290,5 +290,5 @@ You can learn more about how to administer GitLab.
 
 - Udemy: For a more affordable, guided training option, consider
   [GitLab CI: Pipelines, CI/CD, and DevOps for Beginners](https://www.udemy.com/course/gitlab-ci-pipelines-ci-cd-and-devops-for-beginners/) on Udemy.
-- LinkedIn Learning: Check out [Continuous Delivery with GitLab](https://www.linkedin.com/learning/continuous-delivery-with-gitlab) on LinkedIn Learning
+- LinkedIn Learning: Check out [Continuous Delivery with GitLab](https://www.linkedin.com/learning/continuous-integration-and-continuous-delivery-with-gitlab?replacementOf=continuous-delivery-with-gitlab) on LinkedIn Learning
   for another low-cost, guided training option.
diff --git a/doc/administration/lfs/index.md b/doc/administration/lfs/index.md
index 302dc38cf28..3638729a6b6 100644
--- a/doc/administration/lfs/index.md
+++ b/doc/administration/lfs/index.md
@@ -12,7 +12,7 @@ For user documentation about Git LFS, see [Git Large File Storage](../../topics/
 
 Prerequisites:
 
-- Users need to install [Git LFS client](https://git-lfs.github.com) version 1.0.1 or later.
+- Users need to install [Git LFS client](https://git-lfs.com/) version 1.0.1 or later.
 
 ## Enable or disable LFS
 
@@ -439,7 +439,7 @@ To fix this issue, configure your object storage provider's CORS
 settings to allow the GitLab domain. See the following documentation
 for more details:
 
-1. [AWS S3](https://aws.amazon.com/premiumsupport/knowledge-center/s3-configure-cors/)
+1. [AWS S3](https://repost.aws/knowledge-center/s3-configure-cors)
 1. [Google Cloud Storage](https://cloud.google.com/storage/docs/configuring-cors)
 1. [Azure Storage](https://learn.microsoft.com/en-us/rest/api/storageservices/cross-origin-resource-sharing--cors--support-for-the-azure-storage-services).
 
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index 171a441eaec..771b9f46877 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -51,7 +51,7 @@ From left to right, the performance bar displays:
   values in milliseconds, separated by slashes.
   Select to display a modal window with more details. The values, from left to right:
   - **Backend**: time needed for the base page to load.
-  - [**First Contentful Paint**](https://web.dev/first-contentful-paint/):
+  - [**First Contentful Paint**](https://developer.chrome.com/docs/lighthouse/performance/first-contentful-paint/):
     Time until something was visible to the user. Displays `NaN` if your browser does not
     support this feature.
   - [**DomContentLoaded**](https://web.dev/critical-rendering-path-measure-crp/) Event.
diff --git a/doc/ci/cloud_services/google_cloud/index.md b/doc/ci/cloud_services/google_cloud/index.md
index ba6efa4d35c..c1a4aa9e084 100644
--- a/doc/ci/cloud_services/google_cloud/index.md
+++ b/doc/ci/cloud_services/google_cloud/index.md
@@ -30,7 +30,7 @@ To complete this tutorial:
 
 ## Create the Google Cloud Workload Identity Pool
 
-[Create a new Google Cloud Workload Identity Pool](https://cloud.google.com/iam/docs/configuring-workload-identity-federation#oidc) with the following options:
+[Create a new Google Cloud Workload Identity Pool](https://cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds#oidc) with the following options:
 
 - **Name**: Human-friendly name for the Workload Identity Pool, such as `GitLab`.
 - **Pool ID**: Unique ID in the Google Cloud project for the Workload Identity Pool,
@@ -42,7 +42,7 @@ We recommend creating a single _pool_ per GitLab installation per Google Cloud p
 
 ## Create a Workload Identity Provider
 
-[Create a new Google Cloud Workload Identity Provider](https://cloud.google.com/iam/docs/configuring-workload-identity-federation#create_the_workload_identity_pool_and_provider)
+[Create a new Google Cloud Workload Identity Provider](https://cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds#create_the_workload_identity_pool_and_provider)
 inside the Workload Identity Pool created in the previous step, using the following options:
 
 - **Provider type**: OpenID Connect (OIDC).
@@ -86,7 +86,7 @@ To grant your GitLab CI/CD job permissions on Google Cloud, you must:
    service account on Google Cloud resources. These permissions vary significantly based on
    your use case. In general, grant this service account the permissions on your Google Cloud
    project and resources you want your GitLab CI/CD job to be able to use. For example, if you needed to upload a file to a Google Cloud Storage bucket in your GitLab CI/CD job, you would grant this Service Account the `roles/storage.objectCreator` role on your Cloud Storage bucket.
-1. [Grant the external identity permissions](https://cloud.google.com/iam/docs/using-workload-identity-federation#impersonate)
+1. [Grant the external identity permissions](https://cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds#impersonate)
    to impersonate that Service Account. This step enables a GitLab CI/CD job to _authorize_
    to Google Cloud, via Service Account impersonation. This step grants an IAM permission
    _on the Service Account itself_, giving the external identity permissions to act as that
diff --git a/doc/development/performance.md b/doc/development/performance.md
index 21f80364358..02e6c2fd884 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -154,7 +154,7 @@ allowing you to profile which code is running on CPU in detail.
 It's important to note that profiling an application *alters its performance*.
 Different profiling strategies have different overheads. Stackprof is a sampling
 profiler. It samples stack traces from running threads at a configurable
-frequency (for example, 100hz, that is 100 stacks per second). This type of profiling
+frequency (for example, 100 hz, that is 100 stacks per second). This type of profiling
 has quite a low (albeit non-zero) overhead and is generally considered to be
 safe for production.
 
@@ -234,7 +234,7 @@ The following configuration options can be configured:
 - `STACKPROF_INTERVAL`: Sampling interval. Unit semantics depend on `STACKPROF_MODE`.
   For `object` mode this is a per-event interval (every `nth` event is sampled)
   and defaults to `100`.
-  For other modes such as `cpu` this is a frequency interval and defaults to `10100` μs (99hz).
+  For other modes such as `cpu` this is a frequency interval and defaults to `10100` μs (99 hz).
 - `STACKPROF_FILE_PREFIX`: File path prefix where profiles are stored. Defaults
   to `$TMPDIR` (often corresponds to `/tmp`).
 - `STACKPROF_TIMEOUT_S`: Profiling timeout in seconds. Profiling will
@@ -477,7 +477,7 @@ The `mem_*` values represent different aspects of how objects and memory are all
   => {:mem_objects=>1002, :mem_bytes=>32000, :mem_mallocs=>1000}
   ```
 
-- The following example will allocate over 40kB of data, and perform only a single memory allocation.
+- The following example will allocate over 40 kB of data, and perform only a single memory allocation.
    The existing object will be reallocated/resized on subsequent iterations:
 
   ```ruby
@@ -730,7 +730,7 @@ test = +"hello"
 test += " world"
 ```
 
-When adding new Ruby files, please check that you can add the above header,
+When adding new Ruby files, check that you can add the above header,
 as omitting it may lead to style check failures.
 
 ## Banzai pipelines and filters
@@ -825,7 +825,7 @@ source into memory, memory use grows by _at least_ the size of the data source.
 In the case of `readlines`, it grows even further, due to extra bookkeeping
 the Ruby VM has to perform to represent each line.
 
-Consider the following program, which reads a text file that is 750MB on disk:
+Consider the following program, which reads a text file that is 750 MB on disk:
 
 ```ruby
 File.readlines('large_file.txt').each do |line|
@@ -859,7 +859,7 @@ We can see that `heap_live_slots` (the number of reachable objects) jumped to ~2
 which is roughly two orders of magnitude more compared to reading the file line by
 line instead. It was not just the raw memory usage that increased, but also how the garbage collector (GC)
 responded to this change in anticipation of future memory use. We can see that `malloc_increase_bytes` jumped
-to ~30MB, which compares to just ~4kB for a "fresh" Ruby program. This figure specifies how
+to ~30 MB, which compares to just ~4 kB for a "fresh" Ruby program. This figure specifies how
 much additional heap space the Ruby GC claims from the operating system next time it runs out of memory.
 Not only did we occupy more memory, we also changed the behavior of the application
 to increase memory use at a faster rate.
diff --git a/doc/development/sec/security_report_ingestion_overview.md b/doc/development/sec/security_report_ingestion_overview.md
index c1d977c2a17..688986e0eb1 100644
--- a/doc/development/sec/security_report_ingestion_overview.md
+++ b/doc/development/sec/security_report_ingestion_overview.md
@@ -56,7 +56,7 @@ If there is only a Security Finding, a Vulnerability Finding and a Vulnerability
 
 ### Issue creation
 
-If you select `Create issue`, a Vulnerabilities::Feedback record is created as well. The Feedback has a different `feedback_type` and an `issue_id` that’s not `NULL`.
+If you select `Create issue`, a Vulnerabilities::Feedback record is created as well. The Feedback has a different `feedback_type` and an `issue_id` that's not `NULL`.
 
 NOTE:
 Vulnerabilities::Feedback are in the process of being [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/5629). This will later create a `Vulnerabilities::IssueLink` record.
diff --git a/doc/gitlab-basics/start-using-git.md b/doc/gitlab-basics/start-using-git.md
index addeb4bee3a..aec053b95c9 100644
--- a/doc/gitlab-basics/start-using-git.md
+++ b/doc/gitlab-basics/start-using-git.md
@@ -37,7 +37,7 @@ prompt, command shell, and command line). Here are some options:
   - [iTerm2](https://iterm2.com/). You can integrate it with [Zsh](https://git-scm.com/book/id/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Zsh) and [Oh My Zsh](https://ohmyz.sh/) for color highlighting and other advanced features.
 - For Windows users:
   - Built-in command line. On the Windows taskbar, select the search icon and type `cmd`.
-  - [PowerShell](https://learn.microsoft.com/en-us/powershell/scripting/windows-powershell/install/installing-windows-powershell?view=powershell-7).
+  - [PowerShell](https://learn.microsoft.com/en-us/powershell/scripting/windows-powershell/install/installing-windows-powershell?view=powershell-7.3&viewFallbackFrom=powershell-7).
   - Git Bash. It is built into [Git for Windows](https://gitforwindows.org/).
 - For Linux users:
   - Built-in [Linux Terminal](https://ubuntu.com/tutorials/command-line-for-beginners#3-opening-a-terminal).
diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md
index e005c1573bf..192da46d9b5 100644
--- a/doc/topics/git/git_rebase.md
+++ b/doc/topics/git/git_rebase.md
@@ -3,132 +3,98 @@ 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
-description: "Introduction to Git rebase and force-push, methods to resolve merge conflicts through the command line."
+description: "Introduction to Git rebase and force push, methods to resolve merge conflicts through the command line."
 ---
 
-# Introduction to Git rebase and force-push **(FREE)**
+# Introduction to Git rebase and force push **(FREE)**
 
-This guide helps you to get started with rebasing, force-pushing, and fixing
+This guide helps you to get started with rebases, force pushes, and fixing
 [merge conflicts](../../user/project/merge_requests/conflicts.md) locally.
-
-Before diving into this document, make sure you are familiar with using
+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).
 
-## Git rebase
-
-[Rebasing](https://git-scm.com/docs/git-rebase) is a very common operation in
-Git, and has these options:
-
-- [Regular rebase](#regular-rebase).
-- [Interactive rebase](#interactive-rebase).
-
-### Before rebasing
-
 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`). It has a similar
-effect without compromising the work of your contributors.
-
-It's safer to back up your branch before rebasing to make sure you don't lose
-any changes. For example, consider a [feature branch](../../gitlab-basics/start-using-git.md#branches)
-called `my-feature-branch`:
-
-1. Open your feature branch in the terminal:
-
-   ```shell
-   git checkout my-feature-branch
-   ```
-
-1. Checkout a new branch from it:
+consider pulling it instead (`git pull origin master`). Pulling has similar
+effects with less risk compromising the work of your contributors.
 
-   ```shell
-   git checkout -b my-feature-branch-backup
-   ```
+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.
 
-1. Go back to your original branch:
-
-   ```shell
-   git checkout my-feature-branch
-   ```
-
-Now you can safely rebase it. If anything goes wrong, you can recover your
-changes by resetting `my-feature-branch` against `my-feature-branch-backup`:
-
-1. Make sure you're in the correct branch (`my-feature-branch`):
-
-   ```shell
-   git checkout my-feature-branch
-   ```
+When you rebase:
 
-1. Reset it against `my-feature-branch-backup`:
+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
+   the commits it imported from that branch:
 
-   ```shell
-   git reset --hard my-feature-branch-backup
-   ```
+![Git rebase illustration](img/git_rebase_v13_5.png)
 
-If you added changes to `my-feature-branch` after creating the backup branch,
-you lose them when resetting.
+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`.
 
-### Regular rebase
+## Back up a branch before rebase
 
-With a regular rebase you can update your feature branch with the default
-branch (or any other branch).
-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.
+To back up a branch before taking any destructive action, like a rebase or force push:
 
-For example, to update your branch `my-feature-branch` with your
-[default branch](../../user/project/repository/branches/default.md) (here, using `main`):
+1. Open your feature branch in the terminal: `git checkout my-feature`
+1. Check out a new branch from it: `git checkout -b my-feature-backup`
+   Any changes added to `my-feature` after this point are lost
+   if you restore from the backup branch.
+1. Change back to your original branch: `git checkout my-feature`
 
-1. Fetch the latest changes from `main`:
+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:
 
-   ```shell
-   git fetch origin main
-   ```
+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`
 
-1. Checkout your feature branch:
+## Rebase a branch
 
-   ```shell
-   git checkout my-feature-branch
-   ```
+[Rebases](https://git-scm.com/docs/git-rebase) are very common operations in
+Git, and have these options:
 
-1. Rebase it against `main`:
+- **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.
 
-   ```shell
-   git rebase origin/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.
 
-1. [Force-push](#force-push) to your branch.
+### Regular rebase
 
-When you rebase:
+Standard rebases replay the previous commits on a branch without changes, stopping
+only if merge conflicts occur.
 
-1. Git imports all the commits submitted to `main` _after_ the
-   moment you created your feature branch until the present moment.
-1. Git puts the commits you have in your feature branch on top of all
-   the commits imported from `main`:
+Prerequisites:
 
-![Git rebase illustration](img/git_rebase_v13_5.png)
+- You must have permission to force push branches.
 
-You can replace `main` with any other branch you want to rebase against, for
-example, `release-10-3`. You can also replace `origin` with other remote
-repositories, for example, `upstream`. To check what remotes you have linked to your local
-repository, you can run `git remote -v`.
+To update your branch `my-feature` with recent changes from your
+[default branch](../../user/project/repository/branches/default.md) (here, using `main`):
 
-If there are merge conflicts, Git prompts you to fix
-them before continuing the rebase.
+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.
 
-For more information about rebasing, see the [Git documentation](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).
-and [rebasing strategies](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).
+If there are merge conflicts, Git prompts you to fix them before continuing the rebase.
 
-#### Rebase from the GitLab UI
+### From the GitLab UI
 
-You can rebase your feature branch directly from the merge request through a
-[quick action](../../user/project/quick_actions.md#issues-merge-requests-and-epics),
-if all of these conditions are met:
+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:
 
 - No merge conflicts exist for your feature branch.
 - You have the **Developer** role for the source project. This role grants you
@@ -145,49 +111,61 @@ To rebase from the UI:
 GitLab schedules a rebase of the feature branch against the default branch and
 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, the user can't also approve the merge request.
-
 ### Interactive rebase
 
-You can use interactive rebase to modify commits. For example, amend a commit
-message, squash (join multiple commits into one), edit, or delete
-commits. Use a rebase for changing past commit messages,
-and organizing the commit history of your branch to keep it clean.
+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:
 
-NOTE:
-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.
-
-When you want to change anything in recent commits, use interactive
-rebase by passing the flag `--interactive` (or `-i`) to the rebase command.
+```shell
+git rebase -i HEAD~5
+```
 
-For example, if you want to edit the last three commits in your branch
-(`HEAD~3`), run:
+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
-git rebase -i HEAD~3
+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
 ```
 
-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
+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 three commits:
+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. 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 **third** commit.
-   The first commit should be left **unchanged** (`pick`) as we want to squash
-   the second and third into the first.
+   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".
 1. When squashing, Git outputs the commit message so you have a chance to edit it:
@@ -196,50 +174,57 @@ a macOS Zsh shell, you can `squash` or `fixup` (combine) all three commits:
    - 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 force-pushing. If you had pushed these commits already,
-   [force-push](#force-push) instead.
+   push your changes without a force push. If you had pushed these commits already,
+   [force push](#force-push) instead.
 
-The steps for editing through the command line can be slightly
-different depending on your operating system and the shell you're using.
+#### Configure squash options for a project
 
-See [Numerous undo possibilities in Git](numerous_undo_possibilities_in_git/index.md#undo-staged-local-changes-without-modifying-history)
-for a deeper look into interactive rebase.
+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.
 
-## Force-push
+## Force push
 
 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
+Force pushing is not recommended on shared branches, as you risk destroying the
 changes of others.
 
-If the branch you want to force-push is [protected](../../user/project/protected_branches.md),
+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:
 
 - Unprotect it.
-- [Allow force-push](../../user/project/protected_branches.md#allow-force-push-on-a-protected-branch)
+- [Allow force pushes](../../user/project/protected_branches.md#allow-force-push-on-a-protected-branch)
   to it.
 
-Then you can force-push and protect it again.
+Then you can force push and protect it again.
 
 ### `--force-with-lease` flag
 
 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
+flag force pushes. Because it preserves any new commits added to the remote
 branch by other people, it is safer than `--force`:
 
 ```shell
-git push --force-with-lease origin my-feature-branch
+git push --force-with-lease origin my-feature
 ```
 
 ### `--force` flag
 
-The `--force` flag force-pushes, but does not preserve any new commits added to
+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:
 
 ```shell
-git push --force origin my-feature-branch
+git push --force origin my-feature
 ```
+
+## Related topics
+
+- [Numerous undo possibilities in Git](numerous_undo_possibilities_in_git/index.md#undo-staged-local-changes-without-modifying-history)
+for a deeper look into interactive rebases.
+- [Git documentation for branches and rebases](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index 731705fd72e..163848fb256 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -30,7 +30,7 @@ Documentation for GitLab instance administrators is under [LFS administration do
 ## Requirements
 
 - Git LFS must be [enabled in project settings](../../../user/project/settings/index.md#configure-project-visibility-features-and-permissions).
-- [Git LFS client](https://git-lfs.github.com) version 1.0.1 or higher must be installed.
+- [Git LFS client](https://git-lfs.com/) version 1.0.1 or higher must be installed.
 
 ## Known limitations
 
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index 3a9d0c833c1..d73c7d87580 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -148,7 +148,7 @@ due dates.
 
 ## Blocked epics **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33587) in GitLab 15.5: View blocking epics when hovering over the “blocked” icon.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33587) in GitLab 15.5: View blocking epics when hovering over the "blocked" icon.
 
 If an epic is [blocked by another epic](../epics/linked_epics.md#blocking-epics), an icon appears next to its title to indicate its blocked status.
 
diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md
index 7c6e7afb3bc..bc08ccee666 100644
--- a/doc/user/project/members/index.md
+++ b/doc/user/project/members/index.md
@@ -10,12 +10,16 @@ Members are the users and groups who have access to your project.
 
 Each member gets a role, which determines what they can do in the project.
 
-Project members can:
+## Membership types
 
-1. Be [direct members](#add-users-to-a-project) of the project.
-1. [Inherit membership](#inherited-membership) of the project from the project's group.
-1. Be a member of a group that was [shared](share_project_with_groups.md) with the project.
-1. Be a member of a group that was [shared with the project's group](../../group/manage.md#share-a-group-with-another-group).
+Users can become members of a group or project in different ways, which define their membership type.
+
+| Membership type                               | Membership process |
+| --------------------------------------------- | ------------------ |
+| [Direct](#add-users-to-a-project)             | The user is added directly to the current group or project. |
+| [Inherited](#inherited-membership)            | The user is a member of an ancestor group or project that is added to the current group or project. |
+| [Direct shared](share_project_with_groups.md) | The user is a member of a group or project that is shared into the current group or project. |
+| [Inherited shared](../../group/manage.md#share-a-group-with-another-group) | The user is a member of an ancestor of a group or project that is shared into the current group or project. |
 
 ```mermaid
 flowchart RL
@@ -41,6 +45,28 @@ flowchart RL
   G-->|Group C shared with Project A|E
 ```
 
+### Inherited membership
+
+When your project belongs to a group, project members inherit their role
+from the group.
+
+![Project members page](img/project_members_v14_4.png)
+
+In this example:
+
+- Three members have access to the project.
+- **User 0** is a Reporter and has inherited their role in the project from the **demo** group,
+  which contains the project.
+- **User 1** belongs directly to the project. In the **Source** column, they are listed
+  as a **Direct member**.
+- **Administrator** is the [Owner](../../permissions.md) and member of all groups.
+  They have inherited their role in the project from the **demo** group.
+
+If a user is:
+
+- A direct member of a project, the **Expiration** and **Max role** fields can be updated directly on the project.
+- An inherited member from a parent group, the **Expiration** and **Max role** fields must be updated on the parent group.
+
 ## Add users to a project
 
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/247208) in GitLab 13.11 from a form to a modal window [with a flag](../../feature_flags.md). Disabled by default.
@@ -147,28 +173,6 @@ To import users:
 
 After the success message displays, refresh the page to view the new members.
 
-## Inherited membership
-
-When your project belongs to a group, group members inherit their role
-from the group.
-
-![Project members page](img/project_members_v14_4.png)
-
-In this example:
-
-- Three members have access to the project.
-- **User 0** is a Reporter and has inherited their role from the **demo** group,
-  which contains the project.
-- **User 1** belongs directly to the project. In the **Source** column, they are listed
-  as a **Direct member**.
-- **Administrator** is the [Owner](../../permissions.md) and member of all groups.
-  They have inherited their role from the **demo** group.
-
-If a user is a:
-
-- Direct member of a project, the **Expiration** and **Max role** fields can be updated directly on the project.
-- Inherited member from a parent group, the **Expiration** and **Max role** fields must be updated on the parent group.
-
 ## Remove a member from a project
 
 If a user is:
diff --git a/doc/user/project/merge_requests/methods/index.md b/doc/user/project/merge_requests/methods/index.md
index b1d07a740bf..1f7e15ee982 100644
--- a/doc/user/project/merge_requests/methods/index.md
+++ b/doc/user/project/merge_requests/methods/index.md
@@ -199,7 +199,7 @@ In these merge methods, you can merge only when your source branch is up-to-date
 If a fast-forward merge is not possible but a conflict-free rebase is possible,
 GitLab provides:
 
-- The [`/rebase` quick action](../../../../topics/git/git_rebase.md#rebase-from-the-gitlab-ui).
+- The [`/rebase` quick action](../../../../topics/git/git_rebase.md#from-the-gitlab-ui).
 - The option to select **Rebase** in the user interface.
 
 You must rebase the source branch locally before a fast-forward merge if both
diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md
index 9a75c038dbc..bf25c7ef9bb 100644
--- a/doc/user/project/merge_requests/reviews/index.md
+++ b/doc/user/project/merge_requests/reviews/index.md
@@ -35,11 +35,17 @@ Learn more about [how suggested reviewers works and data privacy](data_usage.md)
 
 ### Enable suggested reviewers
 
-Project Maintainers or Owners can enable suggested reviewers by visiting the [project settings](../../settings/index.md).
+Project Maintainers or Owners can enable suggested reviewers by visiting
+the [project settings](../../settings/index.md).
 
-Enabling suggested reviewers will trigger GitLab to create an ML model for your project that will be used to generate reviewers. The larger your project, the longer this can take, but usually, the model will be ready to generate suggestions within a few hours.
+Enabling suggested reviewers triggers GitLab to create an ML model for your
+project that is used to generate reviewers. The larger your project, the longer
+this process can take. Usually, the model is ready to generate suggestions
+within a few hours.
 
-No action is required once the feature is enabled. Once the model is ready, recommendations will populate the Reviewer dropdown list in the right-hand sidebar of a merge request with new commits.
+No action is required after the feature is enabled. After the model is ready,
+recommendations populate the **Reviewer** dropdown list in the right-hand sidebar
+of a merge request with new commits.
 
 ## Review a merge request
 
@@ -147,7 +153,7 @@ To resolve or unresolve a thread when replying to a comment:
 
 Pending comments display information about the action to be taken when the comment is published:
 
-- **{check-circle-filled}** Thread will be resolved.
+- **{check-circle-filled}** Thread is resolved.
 - **{check-circle}** Thread stays unresolved.
 
 ### Add a new comment
@@ -194,7 +200,7 @@ them a notification email.
 ## Comment on multiple lines
 
 > - [Introduced](https://gitlab.com/gitlab-org/ux-research/-/issues/870) in GitLab 13.2.
-> - [Added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49875) click-and-drag features in GitLab 13.8.
+> - [Added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49875) select-and-drag features in GitLab 13.8.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299121) in GitLab 13.9.
 
 When commenting on a diff, you can select which lines of code your comment refers