GitFlow

GitFlow is commonly seen in large-scale development projects. Each branch is dedicated to a specific purpose and policies are made to regulate the interaction between branches. The following figure shows the process of GitFlow.

Process

Master branch
The master branch is the production branch where code is ready to deploy. It is the most stable branch because changes cannot be directly pushed to it. Developers can only merge other branches to the master branch. It is often set as a protected branch by default, on which only the project maintainer can operate.
Hotfix branch
It is a temporary branch created off the master branch for fixing urgent bugs in a live production version. After the bug is fixed, the hotfix branch gets merged into the master branch and tagged with a version number. The bug fix also needs to be merged to the develop branch.
Develop branch
A develop branch is pulled from the master branch and used to merge features. It contains all the code ready to release for integration and system testing.
Release branch
When a new release is coming up, developers create a release branch from the develop branch for release preparations, such as fixing minor bugs and producing documents. Adding new features is not allowed. They should be merged into the develop branch and wait for the next release. When the preparation is complete, the release branch is merged into the master branch and the commit is tagged with a version number. The changes made in the release branch also need to be merged to the develop branch.
Feature branch
Feature branches are pulled from the develop branch for feature development. When the development is complete, they are merged into the develop branch. Feature branches do not interact with the master branch.

Developers add new features in either of the following ways:

Integrate features after reviewed by a dedicated approver.
1. Developers push feature branches to the central repository in CodeArts Repo.
2. Developers then create merge requests for merging the feature branches into the develop branch, and assign the requests to the reviewer.
  
  CodeArts Repo supports MRs. You can choose source branches and target branches. Only repository administrators (project managers, repository creators, and developers granted with repository management permissions) can accept MRs.
3. The approver reviews the merge requests. If the requests are approved, the feature branches are merged into the develop branch and deleted. Otherwise, the approver should explain the reasons of rejections.
Integrate features after self-reviews.
1. Developers merge feature branches to the develop branch in the local repository and delete the feature branches.
2. The local develop branch is then pushed to the central repository in CodeArts Repo.

Advantages

With a branch dedicated for release preparation, a development team can develop new features for a future release on the develop branch while improving the version for the upcoming release. Release is visualized, which means team members can have a clear view of the release status in commit graphs.
Hotfix branches, which can be seen as temporary release branches created off the master branch, enable development teams to fix urgent bugs without interrupting other works. You do not have to wait until next release but can quickly deploy fixes to the production version.
Effective multi-branch mechanism allows for organized development process especially for large-scale projects.
This workflow is more in line with the DevOps philosophies.