Add latest changes from gitlab-org/gitlab@master

1 files changed, 12 insertions, 8 deletions

diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index 45a32655f96..927c1db804a 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -4,11 +4,14 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/forking_workflow.html'
 
 # Project forking workflow
 
-Forking a project to your own namespace is useful if you have no write
-access to the project you want to contribute to. Even if you do have write
-access or can request it, we recommend working together in the same
-repository since it is simpler. See our [GitLab Flow](../../../topics/gitlab_flow.md)
-document more information about using branches to work together.
+Whenever possible, it's recommended to work in a common Git repository and use
+[branching strategies](../../../topics/gitlab_flow.md) to manage your work. However,
+if you do not have write access for the repository you want to contribute to, you
+can create a fork.
+
+A fork is a personal copy of the repository and all its branches, which you create
+in a namespace of your choice. This way you can make changes in your own fork and
+submit them through a merge request to the repo you don't have access to.
 
 ## Creating a fork
 
@@ -27,7 +30,7 @@ Forking a project is, in most cases, a two-step process.
 
 The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
 
-CAUTION: **CAUTION:**
+CAUTION: **Caution:**
 In GitLab 12.6 and later, when project owners [reduce a project's visibility](../../../public_access/public_access.md#reducing-visibility),
 it **removes the relationship** between a project and all its forks.
 
@@ -37,10 +40,11 @@ You can use [repository mirroring](repository_mirroring.md) to keep your fork sy
 
 The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
 
-Without mirroring, to work locally you'll have to user `git pull` to update your local repo with the fork on GitLab. You'll have to fetch locally and push it back to the remote repo to update it.
+Without mirroring, to work locally you'll have to use `git pull` to update your local repo
+with the upstream project, then push the changes back to your fork to update it.
 
 CAUTION: **Caution:**
-With mirroring, before approving a merge request you'll likely to be asked to sync, hence automating it is recommend.
+With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommend.
 
 Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).