Commit 2bfd95d8502607ee8c41675b1711a6710b1e05e1
Exists in
spb-stable
and in
3 other branches
Merge branch 'workflow_documentation' into 'master'
Workflow documentation
Showing
2 changed files
with
33 additions
and
1 deletions
Show diff stats
doc/README.md
@@ -6,7 +6,7 @@ | @@ -6,7 +6,7 @@ | ||
6 | + [Public access](public_access/public_access.md) Learn how you can allow public and internal access to a project. | 6 | + [Public access](public_access/public_access.md) Learn how you can allow public and internal access to a project. |
7 | + [SSH](ssh/README.md) Setup your ssh keys and deploy keys for secure access to your projects. | 7 | + [SSH](ssh/README.md) Setup your ssh keys and deploy keys for secure access to your projects. |
8 | + [Web hooks](web_hooks/web_hooks.md) Let GitLab notify you when new code has been pushed to your project. | 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 | **Administrator documentation** | 11 | **Administrator documentation** |
12 | 12 |
@@ -0,0 +1,32 @@ | @@ -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) |