rhodecode-enterprise-ce Files · docs/collaboration/workflow-fork.rst

auth: don't break hashing in case of user with empty password....

auth: don't break hashing in case of user with empty password. In some cases such as LDAP user created via external scripts users might set the passwords to empty. The hashing uses the md5(password_hash) to store reference to detect password changes and forbid using the same password. In case of pure LDAP users this is not valid, and we shouldn't raise Errors in such case. This change makes it work for empty passwords now.

marcink - - Load All Authors

File last commit:

r1:854a839a default


                r2203:8a18c3c3

default

Download file

             workflow-fork.rst
        
                    43 lines
            
             | 1.3 KiB
            
                | text/x-rst
            
             |
                RstLexer
            
             / docs / collaboration / workflow-fork.rst
          
                    History
                
                 |
                  Source
                 | Raw
                 |Copy content
                 |Copy permalink

        marcink
    
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.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

marcink 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.