##// END OF EJS Templates
integrations: refactor/cleanup + features, fixes #4181...
integrations: refactor/cleanup + features, fixes #4181 * added scopes on integrations, scopes are: - repo only - repogroup children only - root repos only - global (any repo) * integrations schemas now have separate section for the settings (eg. slack) and options (eg. scope/enabled) * added descriptions to integration types * added icons to integration types * added 'create new' integration page * added scope of integration to integrations list * added breadcrumbs for each repo/repogroup/global integrations pages * added sorting to integrations list * added pagination to integrations list * added icons to integrations list * added type filter to integrations list * added message to integrations list if none we found * added extra permissions check on integrations views * db migration from 56 => 57 - adds child_repos_only field * added tests for integrations triggered on events * added tests for integrations schemas * added tests for integrations views for repo/repogroup/admin

File last commit:

r1:854a839a default
r731:7a6d3636 default
Show More
workflow-fork.rst
43 lines | 1.3 KiB | text/x-rst | RstLexer
project: added all source files and assets
r1 .. _fork-flow:
Forking Workflow
================
The forking workflow means that everyone on a team has permission to fork a
|repo| and once they have completed their work, open a pull request to have it
accepted into the main |repo|.
In a forking workflow, not everyone will have write access to the main |repo|.
This means that only those with write access can merge |prs| once they have
been approved. Usually, the forking workflow is used with |hg|, and branching
with |git|.
Forking Overview
----------------
.. image:: ../images/fork-flow.png
:align: center
Setting Up a Forking Workflow
-----------------------------
Setting up a forking workflow in |RCE| would look something like this.
1. Create a user group with write access.
2. Create a user group with read access.
3. Assign team members to the appropriate groups.
4. Users with contributions should open a pull request to
the main |repo| and set a user with write access as the reviewer.
5. Once the |pr| is approved, the write access user would merge it with the
main |repo|.
For more information about setting up user groups, see the :ref:`user-admin-set`
section.
Using a Forking Workflow
------------------------
If you are on a team that uses a forking workflow, see the
:ref:`forks-branches-ref` section for how to fork a |repo|, and also the
:ref:`pull-requests-ref` section.