Branching plan required ?

Question

In the TFS Branching Guide 2010 v1 (here) the ALM Rangers gives you 4 branch plans (scenarios) at the moment.

But in a related project, TFS Guide, also from the ALM Rangers (here), they offer a scenario "No Branch". This is good starting point, because having for example 2 branches (dev and main) will slow down the velocity and does introduce more complexity because of all the FI (forward integrate) and RI (reverse integrate) handling.

It looks for me that ALM Rangers do not sync both projects, because the branching guide 2010 v1 is not offering the "No Branch" plan anymore....

For our company we want to define a guidance that says to use a simple model at start but has the capability to grow when needed. So in fact, we want to start to use and develop directly on the Main branch only, and when QA really will becomes an issue we can drive off to a development branch and merge along the branches.

Is this a good practice to follow ?

Answer 1

How you branch is one of the most important decisions you can make with respect to source code configuration management. It needs to match your organization, your processes, and your teams.

What you decide early will be, to a great degree, what you wind up using forever, so don't take the decision lightly.

My personal recommendation (only because it works for us) is to use the MAIN and DEV branch approach. This provides the ability to perform a level of quality assurance (e.g. trial builds) prior to merging to the MAIN branch. The DEV branch becomes your primary integration branch, so forward integration isn't as much of a burden (since everyone is working off of the DEV branch).

Just to give you some reference, we literally spent between 3 and 6 months discussing our branching strategy, running it through use cases and trying to poke holes in it, before we decided which one to use.