1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
---
stage: Create
group: Code Review
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/#assignments
type: reference, howto
---
# Allow collaboration on merge requests across forks **(FREE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17395) in GitLab 10.6.
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.
This feature is available for merge requests across forked projects that are
publicly accessible.
When enabled for a merge request, members with merge access to the target
branch of the project is granted write permissions to the source branch
of the merge request.
## Enabling commit edits from upstream members
In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/23308),
this setting is enabled by default. It can be changed by users with Developer
permissions to the source project. Once enabled, upstream members can
retry the pipelines and jobs of the merge request:
1. While creating or editing a merge request, select the checkbox **Allow
commits from members who can merge to the target branch**.
1. Once the merge request is created, you can see that commits from members who
can merge to the target branch are allowed.
## 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.
1. Use the copy button to copy the first command and paste them
in your terminal:
```shell
git fetch git@gitlab.com:thedude/awesome-project.git update-docs
git checkout -b thedude-awesome-project-update-docs FETCH_HEAD
```
This fetches the branch of the forked project and then create a local branch
based off the fetched branch.
1. Make any changes you want and commit.
1. Push to the forked project:
```shell
git push git@gitlab.com:thedude/awesome-project.git thedude-awesome-project-update-docs:update-docs
```
Note the colon (`:`) between the two branches. The above command pushes the
local branch `thedude-awesome-project-update-docs` to the
`update-docs` branch of the `git@gitlab.com:thedude/awesome-project.git` repository.
## Troubleshooting
### Pipeline status unavailable from MR page of forked project
When a user forks a project, the permissions on the forked copy are not copied over
from the original project. The creator of the fork must grant permissions to the
forked copy before members in the upstream project can view or merge the changes
in the merge request.
To see the pipeline status from the merge request page of a forked project
going back to the original project:
1. Create a group containing all the upstream members.
1. Go to the **Members** tab in the forked project and invite the newly-created
group to the forked project.
<!-- ## 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. -->
|
