Bring back 'Authorization for Merge Requests'

This text was deleted in 564c37d9b69367fb7384a22edad53c8e75aeb2cb.

Bring back 'Authorization for Merge Requests'
This text was deleted in 564c37d9b69367fb7384a22edad53c8e75aeb2cb.
Jacob Vosmaer
1 parent b9e040f8
Showing 1 changed file with 34 additions and 0 deletions Show diff stats
doc/workflow/authorization_for_merge_requests.md
@@ -0,0 +1,34 @@
+# Authorization for Merge Requests
+
+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.
+
+## Protected branch flow
+
+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.
+
+### Advantages
+
+- fewer projects means less clutter
+- developers need to consider only one remote repository
+
+### Disadvantages
+
+- manual setup of protected branch required for each new project
+
+## Forking workflow
+
+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.
+
+### Advantages
+
+- 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
+
+### Disadvantages
+
+- the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes)
...	...	@@ -0,0 +1,34 @@
	1	+# Authorization for Merge Requests
	2	+
	3	+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.
	4	+
	5	+## Protected branch flow
	6	+
	7	+With the protected branch flow everybody works within the same GitLab project.
	8	+The project maintainers get Master access and the regular developers get Developer access.
	9	+The maintainers mark the authoritative branches as 'Protected'.
	10	+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.
	11	+Only users with Master access can merge changes into a protected branch.
	12	+
	13	+### Advantages
	14	+
	15	+- fewer projects means less clutter
	16	+- developers need to consider only one remote repository
	17	+
	18	+### Disadvantages
	19	+
	20	+- manual setup of protected branch required for each new project
	21	+
	22	+## Forking workflow
	23	+
	24	+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.
	25	+Developers create forks of the authoritative project and push their feature branches to their own forks.
	26	+To get their changes into master they need to create a merge request across forks.
	27	+
	28	+### Advantages
	29	+
	30	+- 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
	31	+
	32	+### Disadvantages
	33	+
	34	+- the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes)
...	...