Skip to content

GIT Workflow that Works …. worked for me!

December 3, 2014

Before I jump to that actual article I want to make sure that we are on the same page as far as the objectives are concerned. Its important because, if the objectives are not clear, the strategy that worked for me, may not work for you. So, here is what I always wanted for my project teams:

  1. To be able to keep on working on the next major release
  2. To be AGILE, meaning they should be able to go to production given a situation
  3. To be able to develop each feature independently
  4. To be able to avoid merge code nightmares

At this point, if you do not resonate with the above objectives, there possibly no point going forward reading this article anymore. Find something else that suits your needs better. Others, please continue…

To achieve the above objectives following GIT workflow has worked for me and I hope many others will resonate:

  • There are only 2 main branches for the team, “master” and “production” at any point in time
  • “master” branch should always be in a production release acceptable by the stakeholder’s state. Meaning, its bug free, stable, and does not have half baked features that can affect the user experience in adverse way (to achieve #2 above)
  • Feature branches are created as per need to develop a given feature which is typically part of the next release (to achieve #3 above)
  • Every feature branch should be “rebased” (git rebase) with master branch at least once a day, (take a call based on the frequency of commits happening in the master branch) to make sure you are working on the most recently committed version of the next release and that you are not stepping upon others shoes who might be working in your close proximity πŸ™‚ (to achieve #4 above)
  • Feature branches are merged back with “master” once the feature is complete and the branch is bug free, meaning, the unit and functional test suite is ran against the branchBug Fixes

How to tackle Bugs
Bugs are of 2 categories. There are ones which are modest :). They do not kill you if you don’t get rid of them until the next scheduled release. At the same time, there are these other ones which are disastrous and possibly contagious. These bugs are the ones which makes your boss call you in the middle of the night and pursue (like, fix it to save your job) you to go and get rid of it immediately. As the nature of the bugs is so different, its nothing but obvious, that the strategy to tackle them is different too. Here’s is what has worked for me:

Modest Bugs
The modest bug fixing should be tacked as any other normal feature development (well both require code change, so as far as a developer is concerned, its all the same πŸ™‚ ) like:

  1. Checkout “master” branch (or make feature branch if the scope of code change is bigger, explained below)
  2. Fix the bug
  3. Run the tests
  4. Commit and Push the fix to “master” branch
  5. Release the big fix with the next scheduled release

Although, it depends on the scope of the code change that is required to make the bug fix, whether you’ll actually create a separate branch for it or not. Normally, the scope is not be as big as that of a typical feature, so you may just end up checking out “master” branch and fixing the bug in it. If not, feel free to create a new “bug” branch and work on the bug and merge it back to master.

Disastrous Bugs
As this bug cannot wait until the next scheduled release, your corse of action is going to be a little different as follows:

  1. Checkout “production” branch
  2. Fix the bug
  3. Run the tests
  4. Commit and Push the fix to “production” branch
  5. Let Jenkins (or the any other tool that you may using for CI) OK the build production build
  6. Deploy the new build to production server (the deployment work flow may be different for you, so follow that)
  7. Merge the production branch back to master so that the big fix is not lost when the next schedule release happens πŸ™‚

Production Deployment
I mentioned deploy to production above. Although the deployment strategy can be different for different teams, there is still a GIT workflow for maintaing the production branch that is still in the scope of this article. So, the scenario is that you are ready with your master branch with all the features that you want to go for the next release. Now the time is to actually make it see the light of day. Its actually very simple. Here is what has worked for me:

  1. Make sure that there is nothing in the “production” branch that is not merged to “master” already
  2. Make sure you CI is OK with it. i.e all tests are passing and green light is flashing
  3. Create a new GIT TAG from the HEAD of the master branch. Give a meaningful name to the TAG, e.g prod_1.1.10 (the versioning strategy is not in the scope of this article, but you can follow whatever best tell us what the release is about)
  4. Deploy the TAG to production instance

And that about everything I wanted to say. Life goes on and you keep repeating this every single time πŸ™‚

One Comment leave one →
  1. stevejansen permalink
    December 16, 2014 8:28 pm

    Hi Sanjeev,

    Enjoyed reading this.

    You’re basically using GitHub Flow (
    with a little bit of the bigger brother, Git Flow (

    I prefer the simpler GitHub Flow for the reasons codified in

    One other small thing – create your tags like like `v1.2.3` and GitHub will automatically creat a GH “release” for your tag. See The `v1.2.3` is an pseudo-convention now.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: