First lets look at the model. A diagram of the model is shown below:
There are a few branching models out there for Git, and GitFlow has some similarities with them, such as using a central repository as the main communication between developers, and having developers work locally, then push branches to the central repo. The main difference between GitFlow and other models is the structure of the branches.
GitFlow considered harmful” might be something you’ve seen before
It seems that GitFlow has been a pretty popular workflow since Driessen’s first article, but with its popularity, there is also some controversy over if the model is as great as people say it is. While I’m not nearly qualified enough to tell you whether it is something you want to use for your next project or not, I’ll go over the positives and negatives, and how to implement it.
How is GitFlow implemented?
To start, GitFlow uses two main branches to keep track of a project: Master and Develop. Master is the branch for official releases and is production ready, and Develop is an integration branch for features to be pushed to. It’s recommended to tag commits in the Master branch with the version number. Depending on the size of your team and the project, it can be difficult to search through the development history with this setup. A benefit of this setup is that all new completed development gets merged back into the Develop branch, which is holding all the features that haven’t been released yet. So when the next release is branched off of Develop, it will automatically contain all of the new stuff that has been finished.
Besides the Master and Develop branches, GitFlow uses supporting branches, one of which being feature branches. Feature branches are exactly how they sound: a branch holding one new feature. When a feature is done, it’s merged into its parent branch: Develop. If you are familiar with the Feature Branch workflow, this part probably sounds the same, which it is. But there’s more.
As soon as the Develop branch has enough features, or a release date is coming up, a release branch is forked from the Develop branch. The Release branch is for no new features, only last-minute fixes and bugs (which we all love), and this also leaves the Develop branch ready to receive features for the next release. (So no one ever has no work to do.) Once the Release branch is ready to ship, it’s merged with the Master (as well as Develop to keep it up-to-date) and tagged with a version number.
Finally, there are Hotfix branches for maintenance. These branches are solely for quickly fixing production releases. This is the only branch that is forked directly off of the Master, then once fixed, is merged back to Master and Develop. (And don’t forget to tag with an updated version number.)
The key benefits of GitFlow are:
- Parallel development
- Easy collaboration
- Support for quick fixes
Some downsides of GitFlow are:
- Not ideal for continuous deployment models
- Can make project history hard to read
- Is slightly complex, and takes time to adjust to
Of course, this is not the only branching model out there, and if you find this flow doesn’t work for you, you have options—Although this can be a wonderful option for traditional release style development.
Sources and more information: