Skip to content

Branching Strategies

A branching strategy refers to the strategy that a software development team uses when writing, merging, and shipping code in the context of a version control system (VCS) such as Git.

A branching strategy defines how a team uses branching to achieve this level of concurrent development.

1. Git Flow

Git flow is a branching model for Git, created by Vincent Driessen in 2010.

The strategy of Git flow is to isolate the work into different types of branches. The two primary branches in Git flow are main and develop. There are three types of supporting branches with different intended purposes: feature, release, and hotfix.

The base branches:

  • main

    Consider main to be the branch where the source code of HEAD always reflects a production-ready state.

  • develop

    Consider develop to be the staging branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.

Supporting branches:

  • feature

    Feature branches are used to develop new features. Feature branches are created from and merged back into develop branches. Feature branches typically exist in developer repos only, not in origin.

  • release

    Release branches are created every iteration (i.e. sprint) from develop branch, which contains a set of features and their associated bug fixes. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number i.e semver, build dates, etc.). The release branch is then subjected to deployed to the staging (integration and regression testing). Any bugs identified during this phase is fixed and committed directly to the release branch. Once the release branch has been confirmed to be free of bugs, it is merged into the main branch and released into production. These fixes are also merged back into develop and other release branches if any exist.

  • fix

    Fixes branches are created from main branch, when issues need an fix upon an undesired state of a live production version. Fix branches needs to be merged back into main and into develop, in order to safeguard that the bugfix is included in the next release.

2. GitHub Flow

GitHub flow is a lightweight, branch-based workflow.

In GitHub flow, the main branch contains your production-ready code. The other branches, feature branches, should contain work on new features and bug fixes and will be merged back into the main branch when the work is finished and properly reviewed.

The base branch:

  • main

Supporting branch:

  • feature

3. Release Flow

Release flow is an industry-standard approach.

4. Trunk-Based Development

Trunk-Based Development is a source-control branching model, where developers collaborate on code in a single branch called trunk (main in Git nomenclature), resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge conflicts, do not break the build.

The base branch:

  • trunk

    Consider trunk to be the branch where the source code of HEAD always contains the latest version.

5. Scaled Trunk-Based Development

Scaled Trunk-Based Development is done with short-lived feature branches. One developer over a couple of days (max) and flowing through Pull-Request style code-review and automation (CI/CD) before integrating (merging) into the trunk (main in Git nomenclature) branch.

The base branch:

  • trunk

    Consider trunk to be the branch where the source code of HEAD always contains the latest version.

Supporting branch:

  • feature

    Short-living feature branches are used to develop new features. Feature branches are created from and merged back into trunk. Feature branches typically exist in developer repos only, not in origin. The style of short-living feature branches is suitable for active committer counts between 2 and 1000.

  • release

    Release branch is a cut from trunk with an optional number of cherry picks that are developed on trunk and then pulled into the branch.

6. References