2019-12-26 22:10:19 +05:30
---
disqus_identifier: 'https://docs.gitlab.com/ee/workflow/forking_workflow.html'
---
# Project forking workflow
2020-04-08 14:13:33 +05:30
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.
2019-12-26 22:10:19 +05:30
## Creating a fork
2020-03-13 15:44:24 +05:30
Forking a project is, in most cases, a two-step process.
2019-12-26 22:10:19 +05:30
2020-03-13 15:44:24 +05:30
1. On the project's home page, in the top right, click the **Fork** button.
2019-12-26 22:10:19 +05:30
![Fork button ](img/forking_workflow_fork_button.png )
2020-03-13 15:44:24 +05:30
1. Click a namespace to fork to. Only namespaces you have Developer and higher [permissions ](../../permissions.md ) for are shown.
NOTE: **Note:**
The project path must be unique within the namespace.
2019-12-26 22:10:19 +05:30
![Choose namespace ](img/forking_workflow_choose_namespace.png )
2020-03-13 15:44:24 +05:30
The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
2020-04-08 14:13:33 +05:30
CAUTION: **Caution:**
2020-03-13 15:44:24 +05:30
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.
2019-12-26 22:10:19 +05:30
2020-03-13 15:44:24 +05:30
## Repository mirroring
2019-12-26 22:10:19 +05:30
2020-03-13 15:44:24 +05:30
You can use [repository mirroring ](repository_mirroring.md ) to keep your fork synced with the original repository. You can also use `git remote add upstream` to achieve the same result.
2019-12-26 22:10:19 +05:30
2020-03-13 15:44:24 +05:30
The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
2020-04-08 14:13:33 +05:30
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.
2020-03-13 15:44:24 +05:30
CAUTION: **Caution:**
2020-04-08 14:13:33 +05:30
With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommend.
2020-03-13 15:44:24 +05:30
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/ ).
2020-01-01 13:55:28 +05:30
2019-12-26 22:10:19 +05:30
## Merging upstream
2020-03-13 15:44:24 +05:30
When you are ready to send your code back to the upstream project,
[create a merge request ](../merge_requests/creating_merge_requests.md ). For **Source branch** ,
choose your forked project's branch. For **Target branch** , choose the original project's branch.
2019-12-26 22:10:19 +05:30
![Selecting branches ](img/forking_workflow_branch_select.png )
2020-03-13 15:44:24 +05:30
Then you can add labels, a milestone, and assign the merge request to someone who can review
your changes. Then click **Submit merge request** to conclude the process. When successfully merged, your
changes are added to the repository and branch you're merging into.
## Removing a fork relationship
2019-12-26 22:10:19 +05:30
2020-03-13 15:44:24 +05:30
You can unlink your fork from its upstream project in the [advanced settings ](../settings/index.md#removing-a-fork-relationship ).
2019-12-26 22:10:19 +05:30
[gitlab flow]: https://about.gitlab.com/blog/2014/09/29/gitlab-flow/ "GitLab Flow blog post"