diff options
| author | Jacob Vosmaer <contact@jacobvosmaer.nl> | 2014-04-18 10:10:40 +0200 |
|---|---|---|
| committer | Jacob Vosmaer <contact@jacobvosmaer.nl> | 2014-04-18 10:10:40 +0200 |
| commit | eadcd278bedd4d83a9e0e5b0bb6285cccc16ac7f (patch) | |
| tree | d2b0aed442333660220d67b8fb6648d47f550cff /doc/workflow | |
| parent | b9e040f8bfbf7723120a35786dbeedc6e8bcc9c4 (diff) | |
| download | gitlab-ce-eadcd278bedd4d83a9e0e5b0bb6285cccc16ac7f.tar.gz | |
Bring back 'Authorization for Merge Requests'
This text was deleted in 564c37d9b69367fb7384a22edad53c8e75aeb2cb.
Diffstat (limited to 'doc/workflow')
| -rw-r--r-- | doc/workflow/authorization_for_merge_requests.md | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/workflow/authorization_for_merge_requests.md b/doc/workflow/authorization_for_merge_requests.md new file mode 100644 index 00000000000..4bbfb8ece56 --- /dev/null +++ b/doc/workflow/authorization_for_merge_requests.md @@ -0,0 +1,34 @@ +# Authorization for Merge Requests + +There are two main ways to have a merge request flow with GitLab: working with protected branches in a single repository, or working with forks of an authoritative project. + +## Protected branch flow + +With the protected branch flow everybody works within the same GitLab project. +The project maintainers get Master access and the regular developers get Developer access. +The maintainers mark the authoritative branches as 'Protected'. +The developers push feature branches to the project and create merge requests to have their feature branches reviewed and merged into one of the protected branches. +Only users with Master access can merge changes into a protected branch. + +### Advantages + +- fewer projects means less clutter +- developers need to consider only one remote repository + +### Disadvantages + +- manual setup of protected branch required for each new project + +## Forking workflow + +With the forking workflow the maintainers get Master access and the regular developers get Reporter access to the authoritative repository, which prohibits them from pushing any changes to it. +Developers create forks of the authoritative project and push their feature branches to their own forks. +To get their changes into master they need to create a merge request across forks. + +### Advantages + +- in an appropriately configured GitLab group, new projects automatically get the required access restrictions for regular developers: fewer manual steps to configure authorization for new projects + +### Disadvantages + +- the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes) |