2016-09-05 10:36:14 +00:00
|
|
|
# Authorization for Merge requests
|
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
There are two main ways to have a merge request flow with GitLab:
|
|
|
|
|
|
|
|
1. Working with [protected branches] in a single repository.
|
|
|
|
1. Working with forks of an authoritative project.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
|
|
|
## Protected branch flow
|
|
|
|
|
|
|
|
With the protected branch flow everybody works within the same GitLab project.
|
|
|
|
|
2018-05-22 10:16:06 +00:00
|
|
|
The project maintainers get Maintainer access and the regular developers get
|
2016-09-05 17:32:37 +00:00
|
|
|
Developer access.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
|
|
|
The maintainers mark the authoritative branches as 'Protected'.
|
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
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.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2018-05-22 10:16:06 +00:00
|
|
|
By default, only users with Maintainer access can merge changes into a protected
|
2016-09-05 17:32:37 +00:00
|
|
|
branch.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
**Advantages**
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
- Fewer projects means less clutter.
|
|
|
|
- Developers need to consider only one remote repository.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
**Disadvantages**
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
- Manual setup of protected branch required for each new project
|
2016-09-05 10:36:14 +00:00
|
|
|
|
|
|
|
## Forking workflow
|
|
|
|
|
2018-05-22 10:16:06 +00:00
|
|
|
With the forking workflow the maintainers get Maintainer access and the regular
|
2016-09-05 17:32:37 +00:00
|
|
|
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.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
To get their changes into master they need to create a merge request across
|
|
|
|
forks.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
**Advantages**
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
- 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.
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
**Disadvantages**
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
- The project need to keep their forks up to date, which requires more advanced
|
|
|
|
Git skills (managing multiple remotes).
|
2016-09-05 10:36:14 +00:00
|
|
|
|
2016-09-05 17:32:37 +00:00
|
|
|
[protected branches]: ../protected_branches.md
|