##// END OF EJS Templates
packaging: Backport bower support utilities...
packaging: Backport bower support utilities To support nixos-16.03 the utilities to build bower components are backported inside of this PR. Once we switch to the new stable branch, we should be able to drop these pieces again.

File last commit:

r1:854a839a default
r725:57489056 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.