10 files changed, 44 insertions, 46 deletions
diff --git a/doc/topics/git/feature_branching.md b/doc/topics/git/feature_branching.md
index f0ded5511ee..d3b2510f4e8 100644
--- a/doc/topics/git/feature_branching.md
+++ b/doc/topics/git/feature_branching.md
@@ -12,7 +12,7 @@ comments: false
 - Keeps changes isolated
 - Consider a 1-to-1 link to issues
 - Push branches to the server frequently
-  - Hint: This is a cheap backup for your work-in-progress code
+  - Hint: Pushing branches is a cheap backup for your work-in-progress code.
 
 ## Feature branching sample workflow
 
diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md
index c0bc7ed4e5c..87fce0b29ff 100644
--- a/doc/topics/git/git_rebase.md
+++ b/doc/topics/git/git_rebase.md
@@ -17,7 +17,7 @@ Before diving into this document, make sure you are familiar with using
 ## Git rebase
 
 [Rebasing](https://git-scm.com/docs/git-rebase) is a very common operation in
-Git. There are the following rebase options:
+Git, and has these options:
 
 - [Regular rebase](#regular-rebase).
 - [Interactive rebase](#interactive-rebase).
@@ -69,15 +69,15 @@ changes by resetting `my-feature-branch` against `my-feature-branch-backup`:
    git reset --hard my-feature-branch-backup
    ```
 
-Note that if you added changes to `my-feature-branch` after creating the backup branch,
+If you added changes to `my-feature-branch` after creating the backup branch,
 you lose them when resetting.
 
 ### Regular rebase
 
 With a regular rebase you can update your feature branch with the default
 branch (or any other branch).
-This is an important step for Git-based development strategies. You can
-ensure that the changes you're adding to the codebase do not break any
+This step is important for Git-based development strategies. You can
+ensure your new changes don't break any
 existing changes added to the target branch _after_ you created your feature
 branch.
 
@@ -148,7 +148,7 @@ executes it as soon as possible.
 The user performing the rebase action is considered
 a user that added commits to the merge request. When the merge request approvals setting
 [**Prevent approvals by users who add commits**](../../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits)
-is enabled, this setting prevents the user from also approving the merge request.
+is enabled, the user can't also approve the merge request.
 
 ### Interactive rebase
 
@@ -158,7 +158,7 @@ commits. Use a rebase for changing past commit messages,
 and organizing the commit history of your branch to keep it clean.
 
 NOTE:
-If you want to keep the default branch commit history clean, you don't need to
+Keeping the default branch commit history clean doesn't require you to
 manually squash all your commits before merging every merge request.
 With [Squash and Merge](../../user/project/merge_requests/squash_and_merge.md),
 GitLab does it automatically.
@@ -176,18 +176,17 @@ git rebase -i HEAD~3
 Git opens the last three commits in your terminal text editor and describes
 all the interactive rebase options you can use. The default option is `pick`,
 which maintains the commit unchanged. Replace the keyword `pick` according to
-the operation you want to perform in each commit. To do so, you need to edit
+the operation you want to perform in each commit. To do so, edit
 the commits in your terminal's text editor.
 
-For example, if you're using [Vim](https://www.vim.org/) as the text editor in
-a macOS's `ZSH` shell, and you want to `squash` or `fixup` all the three commits
-(join them into one):
+For example, with [Vim](https://www.vim.org/) as the text editor in
+a macOS's `ZSH` shell, you can `squash` or `fixup` (combine) all three commits:
 
 <!-- vale gitlab.FirstPerson = NO -->
 
 1. Press <kbd>i</kbd>
    on your keyboard to switch to Vim's editing mode.
-1. Navigate with your keyboard arrows to edit the **second** commit keyword
+1. Use your keyboard arrows to edit the **second** commit keyword
    from `pick` to `squash` or `fixup` (or `s` or `f`). Do the same to the **third** commit.
    The first commit should be left **unchanged** (`pick`) as we want to squash
    the second and third into the first.
@@ -204,7 +203,7 @@ a macOS's `ZSH` shell, and you want to `squash` or `fixup` all the three commits
 
 <!-- vale gitlab.FirstPerson = YES -->
 
-Note that the steps for editing through the command line can be slightly
+The steps for editing through the command line can be slightly
 different depending on your operating system and the shell you're using.
 
 See [Numerous undo possibilities in Git](numerous_undo_possibilities_in_git/index.md#undo-staged-local-changes-without-modifying-history)
@@ -226,8 +225,8 @@ Forcing an update is **not** recommended when you're working on shared
 branches.
 
 Alternatively, you can pass the flag [`--force-with-lease`](https://git-scm.com/docs/git-push#Documentation/git-push.txt---force-with-leaseltrefnamegt)
-instead. It is safer, as it does not overwrite any work on the remote
-branch if more commits were added to the remote branch by someone else:
+instead, as it is safer. This flag preserves any new commits added to the remote
+branch by other people:
 
 ```shell
 git push --force-with-lease origin my-feature-branch
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index db63cee3523..410d2150de5 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -45,7 +45,7 @@ Documentation for GitLab instance administrators is under [LFS administration do
 
 ## Using Git LFS
 
-Let's take a look at the workflow when you need to check large files into your Git
+Let's take a look at the workflow for checking large files into your Git
 repository with Git LFS. For example, if you want to upload a very large file and
 check it into your Git repository:
 
@@ -130,10 +130,10 @@ Technical details about how this works can be found in the [development document
 
 ## Troubleshooting
 
-### Encountered `n` file(s) that should have been pointers, but weren't
+### Encountered `n` files that should have been pointers, but weren't
 
-This error indicates the file (or files) are expected to be tracked by LFS, but for
-some reason the repository is not tracking them as LFS. This issue can be one
+This error indicates the files are expected to be tracked by LFS, but
+the repository is not tracking them as LFS. This issue can be one
 potential reason for this error:
 [Files not tracked with LFS when uploaded through the web interface](https://gitlab.com/gitlab-org/gitlab/-/issues/326342#note_586820485)
 
@@ -160,7 +160,7 @@ To resolve the problem, migrate the affected file (or files) and push back to th
 
 ### error: Repository or object not found
 
-There are a couple of reasons why this error can occur:
+This error can occur for a few reasons, including:
 
 - You don't have permissions to access certain LFS object
 
@@ -232,7 +232,7 @@ Git LFS authenticates the user with HTTP Basic Authentication on every push for
 every object, so user HTTPS credentials are required.
 
 By default, Git has support for remembering the credentials for each repository
-you use. This is described in [Git credentials man pages](https://git-scm.com/docs/gitcredentials).
+you use. To learn more, read the [Git credentials man pages](https://git-scm.com/docs/gitcredentials).
 
 For example, you can tell Git to remember the password for a period of time in
 which you expect to push the objects:
diff --git a/doc/topics/git/merge_conflicts.md b/doc/topics/git/merge_conflicts.md
index 47276ccb0b2..03b7c03c02a 100644
--- a/doc/topics/git/merge_conflicts.md
+++ b/doc/topics/git/merge_conflicts.md
@@ -14,12 +14,12 @@ comments: false
 
 ## Merge conflicts sample workflow
 
-1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
+1. Check out a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
 1. Commit and push.
-1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
-1. Commit and push to master.
+1. Check out `main` and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to `main``.
 1. Create a merge request and watch it fail.
-1. Rebase our new branch with master.
+1. Rebase our new branch with `main`.
 1. Fix conflicts on the `conflicts.rb` file.
 1. Stage the file and continue rebasing.
 1. Force push the changes.
@@ -34,12 +34,12 @@ git checkout -b conflicts_branch
 git commit -am "add line4 and line5"
 git push origin conflicts_branch
 
-git checkout master
+git checkout main
 
 # vi conflicts.rb
 # Add 'Line6' and 'Line7'
 git commit -am "add line6 and line7"
-git push origin master
+git push origin main
 ```
 
 Create a merge request on the GitLab web UI, and a conflict warning displays.
@@ -47,7 +47,7 @@ Create a merge request on the GitLab web UI, and a conflict warning displays.
 ```shell
 git checkout conflicts_branch
 git fetch
-git rebase master
+git rebase main
 
 # Fix conflicts by editing the files.
 
@@ -64,6 +64,6 @@ git push origin conflicts_branch -f
 ## Note
 
 - When to use `git merge` and when to use `git rebase`
-- Rebase when updating your branch with master
-- Merge when bringing changes from feature to master
+- Rebase when updating your branch with `main`
+- Merge when bringing changes from feature to `main`
 - Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>
diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md
index cad29d30af4..91ff4d69c2f 100644
--- a/doc/topics/git/partial_clone.md
+++ b/doc/topics/git/partial_clone.md
@@ -26,7 +26,7 @@ Git 2.22.0 or later is required.
 
 Storing large binary files in Git is normally discouraged, because every large
 file added is downloaded by everyone who clones or fetches changes
-thereafter. This is slow, if not a complete obstruction when working from a slow
+thereafter. These downloads are slow and problematic, especially when working from a slow
 or unreliable internet connection.
 
 Using partial clone with a file size filter solves this problem, by excluding
@@ -65,7 +65,7 @@ The output is longer because Git:
 1. Clones the repository excluding files larger than 1 megabyte.
 1. Downloads any missing large files needed to check out the default branch.
 
-When changing branches, Git may need to download more missing files.
+When changing branches, Git may download more missing files.
 
 ## Filter by object type
 
@@ -147,7 +147,7 @@ For more details, see the Git documentation for
    ```
 
 1. Clone and filter by path. Support for `--filter=sparse:oid` using the
-   clone command is not yet fully integrated with sparse checkout.
+   clone command is not fully integrated with sparse checkout.
 
    ```shell
 
@@ -162,8 +162,7 @@ For more details, see the Git documentation for
    WARNING:
    Git integrations with `bash`, `zsh`, etc and editors that automatically
    show Git status information often run `git fetch` which fetches the
-   entire repository. You many need to disable or reconfigure these
-   integrations.
+   entire repository. Disabling or reconfiguring these integrations might be required.
 
 ## Remove partial clone filtering
 
diff --git a/doc/topics/git/stash.md b/doc/topics/git/stash.md
index d321795e034..638ab559bd3 100644
--- a/doc/topics/git/stash.md
+++ b/doc/topics/git/stash.md
@@ -7,8 +7,8 @@ comments: false
 
 # Git Stash **(FREE)**
 
-We use `git stash` to store our changes when they are not ready to be committed
-and we need to change to a different branch.
+We use `git stash` to store our changes when they are not ready to be committed,
+but we must change to a different branch.
 
 - Stash:
 
@@ -37,7 +37,7 @@ and we need to change to a different branch.
   git stash list --stat
   ```
 
-- To clean our stack we need to manually remove them:
+- To clean our stack, manually remove them:
 
   ```shell
   # drop top stash
@@ -54,7 +54,7 @@ and we need to change to a different branch.
   git stash pop
   ```
 
-- If we meet conflicts we need to either reset or commit our changes.
+- If we meet conflicts, either reset or commit our changes.
 - Conflicts through `pop` doesn't drop a stash afterwards.
 
 ## Git Stash sample workflow
diff --git a/doc/topics/git/tags.md b/doc/topics/git/tags.md
index 8576bcd09ed..d3237fda968 100644
--- a/doc/topics/git/tags.md
+++ b/doc/topics/git/tags.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Tags **(FREE)**
 
-Tags are useful for marking certain deployments and releases for later
+Tags help you mark certain deployments and releases for later
 reference. Git supports two types of tags:
 
 - Annotated tags: An unchangeable part of Git history.
diff --git a/doc/topics/git/terminology.md b/doc/topics/git/terminology.md
index 35814543934..4ce87aa2d11 100644
--- a/doc/topics/git/terminology.md
+++ b/doc/topics/git/terminology.md
@@ -30,7 +30,7 @@ When you want to contribute to someone else's repository, you make a copy of it.
 This copy is called a [**fork**](../../user/project/repository/forking_workflow.md#creating-a-fork).
 The process is called "creating a fork."
 
-When you fork a repo, you create a copy of the project in your own
+When you fork a repository, you create a copy of the project in your own
 [namespace](../../user/group/#namespaces). You then have write permissions to modify the project files
 and settings.
 
@@ -53,10 +53,10 @@ upload the changes to the remote repository on GitLab.
 ## Pull and push
 
 After you save a local copy of a repository and modify the files on your computer, you can upload the
-changes to GitLab. This is referred to as **pushing** to the remote, because you use the command
+changes to GitLab. This action is known as **pushing** to the remote, because you use the command
 [`git push`](../../gitlab-basics/start-using-git.md#send-changes-to-gitlabcom).
 
 When the remote repository changes, your local copy is behind. You can update your local copy with the new
 changes in the remote repository.
-This is referred to as **pulling** from the remote, because you use the command
+This action is known as **pulling** from the remote, because you use the command
 [`git pull`](../../gitlab-basics/start-using-git.md#download-the-latest-changes-in-the-project).
diff --git a/doc/topics/git/troubleshooting_git.md b/doc/topics/git/troubleshooting_git.md
index 0aadde7f7c2..13962ad0376 100644
--- a/doc/topics/git/troubleshooting_git.md
+++ b/doc/topics/git/troubleshooting_git.md
@@ -214,7 +214,7 @@ apply more than one:
      ```shell
      omnibus_gitconfig['system'] = {
        # Set the http.postBuffer size, in bytes
-       "http" => ["postBuffer => 524288000"]
+       "http" => ["postBuffer = 524288000"]
      }
      ```
 
diff --git a/doc/topics/git/useful_git_commands.md b/doc/topics/git/useful_git_commands.md
index 61f170d934a..13a40dd58ca 100644
--- a/doc/topics/git/useful_git_commands.md
+++ b/doc/topics/git/useful_git_commands.md
@@ -8,7 +8,7 @@ type: reference
 # Useful Git commands **(FREE)**
 
 The GitLab support team has collected these commands to help you. You may not
-need to use them often.
+need them frequently.
 
 ## Remotes
 
@@ -42,7 +42,7 @@ git reset <filename>
 
 ### Revert a file to HEAD state and remove changes
 
-There are two options to revert changes to a file:
+To revert changes to a file, you can use either:
 
 - `git checkout <filename>`
 - `git reset --hard <filename>`