The GIT Branching Model

In this post, I would like to share something on the GIT branching model called “GIT-flow”. As a developer, I prefer GIT amongst other tools for repository management. It has completely changed the way developers think of merging and branching. When I was using Subversion as a tool, merging was not an easy task as it many times lead to merge conflicts. With GIT, it is very much easier to do it every now and then. Version control tools are supposed to ease the process in merging and branching.

Development Model:

The repository setup that we use works well with this branching model is the one that has a ‘origin’ repo. Each developer pulls and pushes to origin. Apart from common push and pull actions, a developer may pull or push the changes from other team members to form sub teams before actually transacting to the main repository. For instance, it would be extremely helpful when two or more developers work on big features before pushing the partially-completed work of each person to the origin.

Main Branches:

At the core, the central repository holds two main branches which are the master and develop. We consider the origin/master as the main branch where the source code of HEAD always shows a production-ready state. We consider origin/develop as the main branch where the source code of HEAD shows the state with the latest development changes for the upcoming release and which would not be there in origin/master. It is commonly known as “integration branch” because it has to be merged back to the origin/master once we feel the code which develop branch contains is stable and ready to be released. Hence, each time when changes are merged back to origin/master, it’s called as a new “production release”.

Supporting Branches:

Besides the main branches, the development model has some of the supporting branches which ultimately helps parallel development between a group of developers. This eases tracking the new features, prepares for production releases and to quickly fix the live production issues. These branches will have relatively less life time as they would be removed then and there. There are 3 types of supporting branches which are:

1) Feature Branches

When we have a new feature to be developed, this is the branch that we need to work on. The Feature branch usually originates from master and its merge target would be develop.

2) Release Branches

When we prepare a new production release, this branch is quite useful. It actually originates from master and would be merged back to develop as well as master.

3) Hotfix Branches

This is actually a bugfix branch which should be used when we have some live production issues. It originates from master as other branches and would be merged back to both develop and master.

Each of these branches have a specific purpose and they have strict rules as to their originating branches and merge targets. Though the branches are categorized based on how we use them, they are actual GIT branches.

By using the above development model, we can easily switch over and work on different supporting branches parallelly without any complications. As soon as the branch is done, it can be easily merged/integrated into the appropriate merge targets.

Loganayaki is a Programmer Analyst at Compassites Software Solutions and is currently working on Ruby on Rails projects. She has mainly worked on products across various domains such as Health Care, Social Networking and Event Calendaring. Prior to Compassites, she has worked at Srishti Software and Antrix Techinfo.

Leave a comment