diff options
author | Sytse Sijbrandij <sytse@gitlab.com> | 2014-04-18 08:49:18 +0000 |
---|---|---|
committer | Sytse Sijbrandij <sytse@gitlab.com> | 2014-04-18 08:49:18 +0000 |
commit | 2bfd95d8502607ee8c41675b1711a6710b1e05e1 (patch) | |
tree | 3c38eb54451b7684dba9c7ae6017d2fd17310d9b | |
parent | ad61a61304ea422462ef1f7e71da7f71d91f60b9 (diff) | |
parent | f0f0ac6321310e2d31a67b9025a49b80df5417f3 (diff) | |
download | gitlab-ce-2bfd95d8502607ee8c41675b1711a6710b1e05e1.tar.gz |
Merge branch 'workflow_documentation' into 'master'
Workflow documentation
-rw-r--r-- | doc/README.md | 2 | ||||
-rw-r--r-- | doc/workflow/authorization_for_merge_requests.md | 32 |
2 files changed, 33 insertions, 1 deletions
diff --git a/doc/README.md b/doc/README.md index 6c8fe3a96ce..b73d7bb38e1 100644 --- a/doc/README.md +++ b/doc/README.md @@ -6,7 +6,7 @@ + [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. + [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** diff --git a/doc/workflow/authorization_for_merge_requests.md b/doc/workflow/authorization_for_merge_requests.md new file mode 100644 index 00000000000..4e07d7c04c5 --- /dev/null +++ b/doc/workflow/authorization_for_merge_requests.md @@ -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) |