We need to befriend GitFlow. Here’s why.

For most of you who have read our blogs earlier, my fascination for Git is rather evident. (For those who haven’t : Here’s me rambling about the basics of Git).
But let’s be honest. All that we have seen or known about Git so far from the last post is great, but its great for developers!
  • What about project managers?
  • What about delivery or team leads?
  • What about those brave souls that spend hours and hours managing a long train of parallel development, hoping that everyone manages their code well and hoping that the final release is squeaky clean
  • What about those nightmares that these souls have every time someone talks about fixing something in the current, perfectly running piece of code?
Well, fret not – we have GitFlow.
It is nothing fancy – it’s just git (again). But this time there’s this wonderful way of using it – to make our project managers love us. It was first introduced by Vincent Driessen at nvie as a development model for medium and large-scale development projects which turned out to be really successful.
GitFlow basically defines a strict set of rules for the projects branch structure that provides us with a robust way of managing these projects. It mainly lets us keep our production code always deployment and release ready while allowing multiple developers to work on it simultaneously and provide our app with incremental patches or versions of upgrades. Although GitFlow is meant to be suitable for time-sensitive projects in a releases cycle, I don’t see why we should shy away from using it.

How do we do it?

The principle behind GitFlow is to assign the branches some strict roles and manage the code merges and commits according to those branches.

GitFlow suggests that we start our project with two main branches namely,

  • Master
  • Dev
The Master branch will always have the latest production-ready code which we can roll back to if something goes wrong while we deploy it. While the Dev branch will always have the latest delivered code for the next release.
In addition to these two branches, the GitFlow ideology pushes us to create a few other branches known as ‘Supporting Branches‘. Supporting branches are meant to help the concurrent development between the different developers in the team, as well as help us modularize this entire development, without touching the currently production ready code.
We can name these branches as,
  • Feature-xxxx
  • Release-xxxx
  • Hotfix-xxxx

Feature Branches

Since we can guess it, the feature branches are for features – and only for features.
These branches are children of the Dev branch and have a short life-span of just one feature development. Once this feature/module is developed and the developer is sure that the current instance of his code is working he can then request this feature to be added to the ‘Dev’ branch and hence bringing that build to the latest development milestone.
So, in terms of the command line, we can do,
git checkout -b feature-featureName dev
// Branches out to feature-featureName from the HEAD of dev
And once the development is finished,
git checkout dev 
//switches to dev branch
git merge --no-ff feature-featureName 
//merges feature branch with commit history intact (thanks to --no-ff)
git branch -d feature-featureName
//deletes and closes the feature branch

Release Branches

Release branches are essentially the staging area for our ‘Dev’ branches before we merge them into the ‘Master’ branch. This release branch then stays alive till the time we later merge it into master as our release for that particular development sprint comes up.

Since we branched out from the Dev branch for this release branch, it is considered that the code at the time of branching was (supposedly) a release ready code and hence all the changes that we do from then all would be treated as patches and committed on the release branch itself. These patches should later be merged back into the Dev branch to keep the development copy of our code up-to-date.

Here’s how we do that,
git checkout -b release-1.0.0 dev
// Branches out to release-1.0.0 from the HEAD of dev
Closing out our release branch when the release is finalized,
git checkout master 
//switches to master branch
git merge --no-ff release-1.0.0 
//merges in the release-ready code from release branches to Master
git branch -d release-1.0.0
//deletes and closes the release branch
If we did make any changes to the release branch, then before we delete it we do this,
git checkout dev 
//switches to dev branch
git merge --no-ff release-1.0.0 
//merges in the release-ready code from release branches to dev

It is also suggested that we tag our Master branch at this point in the merge history so that we can refer back to it later. (More on Git tagging here)

We can do this by simply doing the following,

git tag -a v1.0 -m "Some feature added. Security threat score 10/100"

Hotfix Branches

Hotfix branches are nothing but impromptu improvements that we would do on our release-ready code. Just like release branches, hotfix branches also have the version numbers to help us keep track of them.

One essentially important thing we would need to remember is – once the Hotfix development is finished on that particular branch, we need to merge it back in the Master branch and then merge it back into the Dev branch as well.

Although, here’s a rule of thumb we should follow,

“When a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of Dev”

Here’s how we do the branching,
git checkout -b hotfix-1.0.0 master
Closing out our release branch when the release is finalized:
git checkout master 
git merge --no-ff hotfix-1.0.0 
//merges into master, next, merge into dev
git checkout dev
git merge --no-ff hotfix-1.0.0 
git branch -d hotfix-1.0.0
//deletes and closes the hotfixbranch

The ‘Here’s why’ Part

More than anything else, if we follow this approach for our projects, by now, we should have a very detailed Git tree, ready at our disposal. This Git tree can clearly tell us the features that we added to the project incrementally, the releases that we produced (and at what point in the timeline we did them), and what were the patches and hotfixes we applied at what point.

More importantly, for developers, it creates several milestones that they can roll-back to if things don’t go as per the plan, and for project managers, it gives a crystal clear visualization of the development as it goes on in parallel and a picture of rapid feature merges as they come in and happen on the fly (without disrupting the development).

About the author

Shrikar Chonkar

I am a JavaScript loving researcher here at Miracle that is often driven by food, coffee and the love for interesting and curious things! When I am not breaking and building my code, I am often seen cooking or planning my next weekend!

Add comment

Welcome to Miracle's Blog

Our blog is a great stop for people who are looking for enterprise solutions with technologies and services that we provide. Over the years Miracle has prided itself for our continuous efforts to help our customers adopt the latest technology. This blog is a diary of our stories, knowledge and thoughts on the future of digital organizations.

For contacting Miracle’s Blog Team for becoming an author, requesting content (or) anything else please feel free to reach out to us at blog@miraclesoft.com.

Who we are?

Miracle Software Systems, a Global Systems Integrator and Minority Owned Business, has been at the cutting edge of technology for over 24 years. Our teams have helped organizations use technology to improve business efficiency, drive new business models and optimize overall IT.

Recent Posts