diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-28 12:09:05 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-28 12:09:05 +0000 |
commit | 5426ca9908085087d465fa52800335f408eb965a (patch) | |
tree | 6b442cff02fda9402fc7bb9cf9986e363dd5aaa6 /doc/user/project/repository | |
parent | 67cdfd2683b89bce260600fa8925eefdcdf9e3e5 (diff) | |
download | gitlab-ce-5426ca9908085087d465fa52800335f408eb965a.tar.gz |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user/project/repository')
-rw-r--r-- | doc/user/project/repository/forking_workflow.md | 20 |
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/). |