2019-06-09 22:25:13 +00:00
|
|
|
---
|
|
|
|
type: concepts
|
|
|
|
---
|
|
|
|
|
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:
|
|
|
|
|
2019-06-09 22:25:13 +00:00
|
|
|
1. Working with [protected branches](../protected_branches.md) in a single repository.
|
2016-09-05 17:32:37 +00:00
|
|
|
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
|
|
|
|
2019-06-09 22:25:13 +00:00
|
|
|
<!-- ## Troubleshooting
|
|
|
|
|
|
|
|
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
|
|
|
one might have when setting this up, or when something is changed, or on upgrading, it's
|
|
|
|
important to describe those, too. Think of things that may go wrong and include them here.
|
|
|
|
This is important to minimize requests for support, and to avoid doc comments with
|
|
|
|
questions that you know someone might ask.
|
|
|
|
|
|
|
|
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
|
|
|
If you have none to add when creating a doc, leave this section in place
|
|
|
|
but commented out to help encourage others to add to it in the future. -->
|