Git branching models

|---Module:text|Size:Small---|

This article aims at sharing major pains and advantages between branching models without making any judgment on which model is better and which should be used, but rather as a guide for better decision making.

GitFlow

This flow promotes the existence of 2 main branches: a “master” branch, where the Production version of the code is saved and where the release numbers are managed; and a “develop” branch, where all new developments are committed and pushed. Supporting branches like “feature”, “hotfixes” and “release” could be of great help, especially when you want to prepare, maintain and record releases, making sure that you don’t leave any important piece of code behind.

|---Module:image|Size:Small---|

|---Module:text|Size:Small---|

The main vision of this branching modelis that a “master” is created and then, taking it as a baseline, the “develop” branch is initially formed. All features (“feature” branches) are established using the “develop” branch as a baseline and, when features are done, they are merged back to be developed. Besides, all hotfixes are conceived using the “master” branch as a baseline and must be merged back to “master” when the fix is done - those changes must be merged simultaneously to “develop”.

When a release is about to be prepared, a “release” branch should be created using the HEAD of “develop” as a baseline. Some bug fixing could be made over this kind of branch, but when the fix is done, it must be incorporated back on the “develop”. Finally, when the release is ok, a merge to “master” is done and a Tag version is built. At this time, the branch is no longer needed, and it can be deleted.

OneFlow

OneFlow consists of having only one eternal branch - “master”. In comparison to the GitFlow model, the direct difference is the absence of the “develop” branch. This approach of one long-lived branch doesn’t mean that there aren’t other branches involved using it. OneFlow should not be used when the new product release is not based on the previous release, which is the same requirement when using GitFlow.

In OneFlow, features branches are conceived from the “master” branch and not from the “develop” branch, like in GitFlow:

|---Module:image|Size:Small---|

|---Module:text|Size:Small---|

Features may be associated with a new requirement, allowing developers to be more agile in the moment of the creation of a new release based on the approved requirements.

For each production release, a new branch “release” can be created. For example, producing a new branch from the “master” and merging each requirement (from the feature branch) to this new branch and tagging it.  And Later, the “release” branch merged to the “master”:

|---Module:image|Size:Small---|

|---Module:text|Size:Small---|

This release branch strategy is applied wherever a hotfix is needed to be applied – the difference is in the intent. A hotfix branch is an unwanted but necessary exception, typically because of some critical issues detected in the latest release.

In summary, to determine which model works for you, you must consider your project’s delivery method.