2019-09-04 21:01:54 +05:30
---
2020-10-24 23:57:45 +05:30
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/engineering/ux/technical-writing/#designated-technical-writers
2019-09-04 21:01:54 +05:30
type: reference, howto
---
2018-11-08 19:23:39 +05:30
# Allow collaboration on merge requests across forks
2020-03-13 15:44:24 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17395) in GitLab 10.6.
2019-03-02 22:35:43 +05:30
When a user opens a merge request from a fork, they are given the option to allow
upstream members to collaborate with them on the source branch. This allows
the members of the upstream project to make small fixes or rebase branches
before merging, reducing the back and forth of accepting external contributions.
2018-11-08 19:23:39 +05:30
This feature is available for merge requests across forked projects that are
2019-03-02 22:35:43 +05:30
publicly accessible.
2018-11-08 19:23:39 +05:30
When enabled for a merge request, members with merge access to the target
branch of the project will be granted write permissions to the source branch
of the merge request.
2019-03-02 22:35:43 +05:30
## Enabling commit edits from upstream members
2018-11-08 19:23:39 +05:30
The feature can only be enabled by users who already have push access to the
2019-03-02 22:35:43 +05:30
source project and only lasts while the merge request is open. Once enabled,
upstream members will also be able to retry the pipelines and jobs of the
merge request:
2021-01-03 14:25:43 +05:30
1. While creating or editing a merge request, select the checkbox **Allow
commits from members who can merge to the target branch**.
2019-03-02 22:35:43 +05:30
![Enable contribution ](img/allow_collaboration.png )
2021-01-03 14:25:43 +05:30
1. Once the merge request is created, you can see that commits from members who
2019-03-02 22:35:43 +05:30
can merge to the target branch are allowed.
![Check that contribution is enabled ](img/allow_collaboration_after_save.png )
## Pushing to the fork as the upstream member
If the creator of the merge request has enabled contributions from upstream
members, you can push directly to the branch of the forked repository.
Assuming that:
- The forked project URL is `git@gitlab.com:thedude/awesome-project.git` .
- The branch of the merge request is `update-docs` .
Here's how the process would look like:
1. First, you need to get the changes that the merge request has introduced.
Click the **Check out branch** button that has some pre-populated
commands that you can run.
![Check out branch button ](img/checkout_button.png )
2019-12-21 20:55:43 +05:30
1. Use the copy button to copy the first command and paste them
2019-03-02 22:35:43 +05:30
in your terminal:
2020-03-13 15:44:24 +05:30
```shell
2019-03-02 22:35:43 +05:30
git fetch git@gitlab.com:thedude/awesome-project.git update-docs
git checkout -b thedude-awesome-project-update-docs FETCH_HEAD
```
This will fetch the branch of the forked project and then create a local branch
based off the fetched branch.
2018-11-08 19:23:39 +05:30
2019-03-02 22:35:43 +05:30
1. Make any changes you want and commit.
1. Push to the forked project:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-03-02 22:35:43 +05:30
git push git@gitlab.com:thedude/awesome-project.git thedude-awesome-project-update-docs:update-docs
```
2018-11-08 19:23:39 +05:30
2019-03-02 22:35:43 +05:30
Note the colon (`:`) between the two branches. The above command will push the
local branch `thedude-awesome-project-update-docs` to the
`update-docs` branch of the `git@gitlab.com:thedude/awesome-project.git` repository.
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X` .
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->