Updated on 2023-07-25 GMT+08:00

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:

  • Incorporate features after the features are reviewed by a dedicated reviewer.
    1. Developers push feature branches to the central repository in CodeHub.
    2. Developers then create merge requests for merging the feature branches into the develop branch, and assign the requests to the reviewer.

      CodeHub supports merge requests. Only repository administrators (project managers, repository creators, and developers granted with repository management permissions) can accept merge requests.

    3. Reviewers review the merge requests. If the requests are approved, the feature branches are merged into the develop branch and deleted. Otherwise, the reviewer 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 CodeHub.

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. Bug fixes do not have to wait until next release but can be quickly deployed 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.

Disadvantages

  • High learning thresholds.
  • Impact will be greater if development teams do not comply with their specified workflow policies.