Merge branch 'workflow_documentation' into 'master'
Workflow documentation
This commit is contained in:
commit
2bfd95d850
|
@ -6,7 +6,7 @@
|
||||||
+ [Public access](public_access/public_access.md) Learn how you can allow public and internal access to a project.
|
+ [Public access](public_access/public_access.md) Learn how you can allow public and internal access to a project.
|
||||||
+ [SSH](ssh/README.md) Setup your ssh keys and deploy keys for secure access to your projects.
|
+ [SSH](ssh/README.md) Setup your ssh keys and deploy keys for secure access to your projects.
|
||||||
+ [Web hooks](web_hooks/web_hooks.md) Let GitLab notify you when new code has been pushed to your project.
|
+ [Web hooks](web_hooks/web_hooks.md) Let GitLab notify you when new code has been pushed to your project.
|
||||||
+ [Workflow](workflow/workflow.md) Learn how to use Git and GitLab together.
|
+ [Workflow](workflow/README.md) Learn how to use Git and GitLab together.
|
||||||
|
|
||||||
**Administrator documentation**
|
**Administrator documentation**
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,32 @@
|
||||||
|
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)
|
Loading…
Reference in New Issue