Download as
Browse Code »

Commit 56a5bc690d65199311009bb1e54f22379ae9ca0b

Authored by Sytse Sijbrandij
2 parents d41e404e cf9c8e73
Exists in spb-stable and in 3 other branches 6-8-stable, 7-0-stable, 7-0-stable-spb

Merge branch 'mr_workflow' into 'master' 

Add documentation for MR workflow
Showing 1 changed file with 36 additions and 0 deletions   Show diff stats
app/views/help/workflow.html.haml
  Diff comments   View file @56a5bc6
1 1 = render layout: 'help/layout' do
2 2 %h3.page-title Workflow
3 3  
  4 + %h4 Summary
  5 +
4 6 %ol.help
5 7 %li
6 8 %p Clone project
... ... @@ -35,3 +37,37 @@
35 37 %li
36 38 %p Your team lead will review code & merge it to main branch
37 39  
  40 + %h3 Authorization for Merge Requests
  41 + %p
  42 + 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.
  43 +
  44 + %h4 Protected branch flow
  45 + %p
  46 + With the protected branch flow everybody works within the same GitLab project.
  47 + The project maintainers get Master access and the regular developers get Developer access.
  48 + The maintainers mark the authoritative branches as 'Protected'.
  49 + 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.
  50 + Only users with Master access can merge changes into a protected branch.
  51 +
  52 + %h5 Advantages
  53 + %ul
  54 + %li fewer projects means less clutter
  55 + %li developers need to consider only one remote repository
  56 +
  57 + %h5 Disadvantages
  58 + %ul
  59 + %li manual setup of protected branch required for each new project
  60 +
  61 + %h4 Forking workflow
  62 + %p
  63 + 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.
  64 + Developers create forks of the authoritative project and push their feature branches to their own forks.
  65 + To get their changes into master they need to create a merge request across forks.
  66 +
  67 + %h5 Advantages
  68 + %ul
  69 + %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
  70 +
  71 + %h5 Disadvantages
  72 + %ul
  73 + %li all developers on the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes)
... ...