diff options
| author | Sytse Sijbrandij <sytse@gitlab.com> | 2014-02-13 17:39:13 +0400 |
|---|---|---|
| committer | Sytse Sijbrandij <sytse@gitlab.com> | 2014-02-13 17:39:13 +0400 |
| commit | 56a5bc690d65199311009bb1e54f22379ae9ca0b (patch) | |
| tree | 7c2f6cf97725bdd284069d3a37d5fdfae3e3aeb9 | |
| parent | d41e404e09c79394ff1938eee01b56345edc6ed9 (diff) | |
| parent | cf9c8e7382254b7abc928ec5af093da736d1ec3f (diff) | |
Merge branch 'mr_workflow' into 'master'
Add documentation for MR workflow
| -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) |