Geeks With Blogs
Gaurav Bodar - ALM Consultant, TFS specialist ALM, TFS, Agile, Scrum, Sharepoint, IT Service

I think the problem with branching and merging guidelines are similar to those programming logic, where you should always use the basic ideas first before thinking advanced. Certainly most branching guidelines are written considering the Complex issues with big teams.

If you have small team workings on small projects than you don’t want to create 10 different branches by reading the branching and merging guide available on codeplex. Anyway here is snippet from the branching guide about how to pick your strategy.


For more information on this table please check

So I would say for 70% of teams out there first two basic and standard strategies are enough. Let me answer some common questions for branching.

How many branches should I create?
Best answer is none if it’s not required. The common requirement of branching is Code isolation. If you have very stable line of code than create label (TFS) or TAG in SVN, which would be highly optimistic. But not impossible. However my recommendation would be 3 branches generally. Please do remember branching is kind of the road which you have to walk back, so don’t run in one direction because more branches means you could almost never finish the complex merging.

Anyway I would create these branches for managing my code

  • Main– This is what gets deployed
  • Dev – Typically known as the Quality line
  • Release – Needed when production breaks so often.


Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Main Branch – If you have small team than start adding your code into source control system and that becomes your main line or create main directory under your project source control path and you are good. This is your line which should never break otherwise you don’t know how to use source control system.

Development Branch – If you are nervous that your code on main line would break because some sensational development team members, than you want to redirect those people onto this branch. Remember that whatever tool or terminology you use in the world if you have garbage input you can’t expect perfect output. Hence to transfer quality from this branch to main line, use strategies like

  • TDD or unit testing on your code
  • Check-in Policy or gated check-in
  • Code reviews before check-in

Experiment using Git: If you are using TFS 2012 and further you could utilize the GIT-TFS Combination here. Git is great for Frictionless Context switching and dispose experiments. So if developer is not too confident for example during first sprint, they could create local branches using Git and manage their work before transferring it to TFS using git-tf

Release Branch

Developers would work in either Dev or Main line. When you release, you’ll do a merge from Main into Release, and hopefully it won’t needed, But if you need to fix something fast, the Release line will be there for you. Make the fix in the release line, test it, deploy it, and save the day. After you pulse returns to normal, merge the fix into Main and if necessary from Main into Dev.

As I mentioned earlier, for more scenarios like branch by release, feature, code promotion and all other advanced branching strategy visual studio Branching guide should be referred.

Posted on Thursday, October 10, 2013 5:35 PM TFS , team foundation server , branching , git | Back to top

Comments on this post: Branching Strategy

# re: Branching Strategy
Requesting Gravatar...
Thanks for sharing this wonderful idea. I might be able to apply this idea in my projects. - Marla Ahlgrimm
Left by Julie Vyrne on Nov 02, 2016 8:55 PM

comments powered by Disqus

Copyright © Gaurav Bodar | Powered by: