Commit 56a5bc690d65199311009bb1e54f22379ae9ca0b
Exists in
spb-stable
and in
3 other branches
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
| 1 | = render layout: 'help/layout' do | 1 | = render layout: 'help/layout' do |
| 2 | %h3.page-title Workflow | 2 | %h3.page-title Workflow |
| 3 | 3 | ||
| 4 | + %h4 Summary | ||
| 5 | + | ||
| 4 | %ol.help | 6 | %ol.help |
| 5 | %li | 7 | %li |
| 6 | %p Clone project | 8 | %p Clone project |
| @@ -35,3 +37,37 @@ | @@ -35,3 +37,37 @@ | ||
| 35 | %li | 37 | %li |
| 36 | %p Your team lead will review code & merge it to main branch | 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) |