GitFlow is branching model for Git that was introduced by Vincent Driessen on a blog post back in 2010 which is really effective when It comes to large scale projects. It’s a really great strategy for properly separate your work, versioning, release management, collaboration and scaling.

In this series of posts, we will talk about a collection of extensions to Git that allows us to easily use the GitFlow branching strategy as well. This set of extension is also called GitFlow. So, I will use GitFlow when mentioning the Branching Model as well as the set of extensions and how to use it.

GitFlow isolates new development work from finished work. Which helps to prevent what I call feature bleeding which is parts of unfinished work ending up on a production release. Which might happen if you are not careful. By isolating features, we ensure that unfinished work is never released to production. It improves collaboration by allowing two or more developers to work on the same feature because the feature developments happen on a dedicated branch and its sandboxed to that branch. It makes it easy to share work and see what other are working on.

GitFlow allows us to have a Release Staging Area that includes all the finished features that are not yet released to production on a separate branch. This branch is normally called develop branch. This makes it easy to isolate the finished work and create releases for production. Released software are bound to have bugs that need immediate fixing and GitFlow allows us to fix these issues with the use of HotFix branches. (Which we will discuss later) This allows teams to quickly fix issues with out having the worry of accidentally merging in new development work in to the HotFix release. Let’s look at GitFlow in detail.

The GitFlow consists of 2 main branch types.

• The Main Branches
• The Support Branches

The Main branches includes master and develop branches which has infinite lifetime. The master branch (rather origin/master) should always reflects the production ready state. And the develop branch (origin/develop) contains the latest delivered development changes that will go for the next release.

Apart from this this model is supplemented with Support Branches with a limited lifetime. These support branches allow us to easily track features, preparation for production releases and to quickly fix production bugs apart from other benefits. The main branches of these Support Branches include,

• Feature Branches
• Release Branches
• Hotfix Branches

Feature branches are branched off from develop branch and used to develop features that should be included in the next release. These branches MUST be merged back in to develop branch.

Release branches are also branched off from develop branch and this is done in preparation for a production release. The production release is done using this branch and there may be minor fixed committed to this branch during the prep for the release. This branch MUST be merged back in to develop and master after a release.

HotFix branches are branched off from the master branch. These are used to unplanned production release. This is caused by a bug in production that needs immediate fixing and a production release afterwards. After the release these branches MUST be merged back in to develop and master branches.

Let’s look at a diagram that shows the flow between these branches.

So guys, that was a quick intro in to the GitFlow branching model and its value for a large scale development projects. In the coming post’s we will discuss how to install the GitFlow: a set of extensions for Git to make use of this branching strategy.

GitFlow: A Better Branching Strategy for Your Projects - All Articles

• #1 Introduction to the Branching Model (This Article)
• #2 Installing and Setting Up GitFlow On Windows