Download as
Browse Code »

Commit 2bfd95d8502607ee8c41675b1711a6710b1e05e1

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

Merge branch 'workflow_documentation' into 'master' 

Workflow documentation
Showing 2 changed files with 33 additions and 1 deletions   Show diff stats
doc/README.md
  Diff comments   View file @2bfd95d
... ... @@ -6,7 +6,7 @@
6 6 + [Public access](public_access/public_access.md) Learn how you can allow public and internal access to a project.
7 7 + [SSH](ssh/README.md) Setup your ssh keys and deploy keys for secure access to your projects.
8 8 + [Web hooks](web_hooks/web_hooks.md) Let GitLab notify you when new code has been pushed to your project.
9   -+ [Workflow](workflow/workflow.md) Learn how to use Git and GitLab together.
  9 ++ [Workflow](workflow/README.md) Learn how to use Git and GitLab together.
10 10  
11 11 **Administrator documentation**
12 12  
... ...
doc/workflow/authorization_for_merge_requests.md 0 → 100644
  Diff comments   View file @2bfd95d
... ... @@ -0,0 +1,32 @@
  1 +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.
  2 +
  3 +## Protected branch flow
  4 +
  5 +With the protected branch flow everybody works within the same GitLab project.
  6 +The project maintainers get Master access and the regular developers get Developer access.
  7 +The maintainers mark the authoritative branches as 'Protected'.
  8 +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.
  9 +Only users with Master access can merge changes into a protected branch.
  10 +
  11 +### Advantages
  12 +
  13 +- fewer projects means less clutter
  14 +- developers need to consider only one remote repository
  15 +
  16 +### Disadvantages
  17 +
  18 +- manual setup of protected branch required for each new project
  19 +
  20 +## Forking workflow
  21 +
  22 +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.
  23 +Developers create forks of the authoritative project and push their feature branches to their own forks.
  24 +To get their changes into master they need to create a merge request across forks.
  25 +
  26 +### Advantages
  27 +
  28 +- 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
  29 +
  30 +### Disadvantages
  31 +
  32 +- the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes)
... ...