diff options
author | Jacob Vosmaer <contact@jacobvosmaer.nl> | 2014-02-13 14:25:43 +0100 |
---|---|---|
committer | Jacob Vosmaer <contact@jacobvosmaer.nl> | 2014-02-13 14:25:43 +0100 |
commit | cf9c8e7382254b7abc928ec5af093da736d1ec3f (patch) | |
tree | 7c2f6cf97725bdd284069d3a37d5fdfae3e3aeb9 /app/views/help | |
parent | d41e404e09c79394ff1938eee01b56345edc6ed9 (diff) | |
download | gitlab-ce-cf9c8e7382254b7abc928ec5af093da736d1ec3f.tar.gz |
Explanation MR workflow and authorization
Diffstat (limited to 'app/views/help')
-rw-r--r-- | app/views/help/workflow.html.haml | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/app/views/help/workflow.html.haml b/app/views/help/workflow.html.haml index 2b8950cd5c2..2ac5cd3a650 100644 --- a/app/views/help/workflow.html.haml +++ b/app/views/help/workflow.html.haml @@ -1,6 +1,8 @@ = render layout: 'help/layout' do %h3.page-title Workflow + %h4 Summary + %ol.help %li %p Clone project @@ -35,3 +37,37 @@ %li %p Your team lead will review code & merge it to main branch + %h3 Authorization for Merge Requests + %p + 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. + + %h4 Protected branch flow + %p + 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. + + %h5 Advantages + %ul + %li fewer projects means less clutter + %li developers need to consider only one remote repository + + %h5 Disadvantages + %ul + %li manual setup of protected branch required for each new project + + %h4 Forking workflow + %p + 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. + + %h5 Advantages + %ul + %li 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 + + %h5 Disadvantages + %ul + %li all developers on the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes) |