Forking Workflow

The forking workflow is suitable for outsourcing, crowdsourcing, crowdfunding, and open source projects. One of the features that distinguish this workflow is that every contracting developer has a personal public repository, which is forked from the project public repository. Developers can perform operations on the forks without the need of being authorized by the project maintainer. The following figure shows the process of the forking workflow.

Click to enlarge

Process

Developers fork the project public repository to create personal public ones.
The personal public repositories are cloned to their local computers for development.
After the development is complete, developers push changes to their personal public repositories.
Developers file merge requests to the project maintainer for merge to the project public repository.
The project maintainer pulls changes to the local computer and reviews the code. If the code is approved, it is pushed to the project public repository.

If the code written by a developer is not approved and therefore, not merged to the project public repository, other developers can still pull the code from the personal public repository of the developer for references.

Advantages

Code collaboration is easier. Developers can share their code by pushing it to their personal public repositories for others to pull, unlike some workflows where developers cannot see others' work until it is merged into the project repository.
Project maintainers do not have to grant permissions on project public repositories to every contributor.
Merge requests serve as an important guard for code security.
The three workflows introduced previously can be incorporated into the forking workflow based on project requirements.