Introduction
Git-flow is a very popular workflow to utilize git branching in an efficient manner. The original post can be found on this link and today I’ll try to summarize and provide a very high level overview for easy reference.
In a nutshell GitFlow is based on centralized distribution model. Every developer can push to a central blessed repository but GitFlow also encourages developers to exchange data directly when appropriate. So this is a mixed distribution model with peer-to-peer elements.
The core of GitFlow is its branching model, which is very detailed. It relies on two long-lived branches, typically master and develop.
master represent the stable version of the application while develop is unstable.
It defines a number of other branches such as feature, release, hotfix.
GitFlow Branches
To understand GitFlow branches, you can broadly partition them into two groups.
- Un-stable Branches (feature, develop)
- Stable Branches (release, hotfix, master)
The un-stable branches used for development work. develop is integration branch and then we have feature branches (one per feature).
Stable branches used mostly for releases. master is integration branch (but it is different from develop, because develop is not stable in general). So, we only merge develop –> master, when we know, we have a working system.
Then we have release branches, a separate one for each release. They are used to prepare a release.
hotfix branches are used for problem fix on code that is already in production.
Constraints
These define which branches can branch-off from which other branches and which branches can merge into which other branches. BTW, I say merge, because its always merging, never rebasing.
GitFlow believes in maintaining a truthful and trackable history. You are not suppose to change that history by rebasing.
Following are constraints mentioned from original post:
Feature Branches
May branch off from:
develop
Must merge back into:
develop
Release branches
May branch off from:
develop
Must merge back into:
develop and master
Hotfix branches
May branch off from:
master
Must merge back into:
develop and master
There are more rules about what to tag and when and so on. GitFlow also gives you the naming conventions that you should use for some of your branches.
All these constraints means that GitFlow is pretty tightly defined and that this procedure has some defined advantages.
Growing your own Flow
Beside benefits of GitFlow, you can adapt some simple strategies to avoid issues with complex git branching constraints. e.g. a feature branch can contain code developed over several months and when it is done and its merged in a big check-in can cause conflict/ issues.
You can e.g. merge feature branches more often, if this help in simplifying the workflow for your particular needs. In general, it is recommended to integrate more often when possible.
GitFlow is not for every project. Based on project and teams need, you can also grow your own flow step by step by initially starting with a simple flow.
Summary
In this post, we discussed the GitFlow workflow. It is a bit complex but same time very popular and flexible workflow. However, over the years, new techniques, variations have emerged and depending on the project and team, some other workflow might be more useful. Author Vincent Driessen, wrote Note of reflection (March 5, 2020) after 10 years of original post, addressing this point, you can read on this link.
Let me know, if you have some comments or questions. Till next time, Happy Coding.