##// END OF EJS Templates
rhodecode-enterprise-ce
RSS
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
marcink - - Load All Authors

File last commit:

r1:854a839a default
r731:7a6d3636 default
Show More
workflow-fork.rst
43 lines | 1.3 KiB | text/x-rst | RstLexer
/ docs / collaboration / workflow-fork.rst
History | Annotation | Raw |Copy content |Copy permalink

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

../images/fork-flow.png

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.