VSTS Ranger Branching Guidance – A Question on Separate Branches for each Change Request

Question from TFS Branching Guide 2.0 on Codeplex:

“I am creating a new branch for each 'Change Request' that comes from the client - I love the idea of isolating the code this way. Do I have to create a new build definition for each, or am I missing something really straight forward? It seems like overkill for the smaller changes, but I want to keep a consistent set of rules - so if one change request gets a branch then so do all of them.”

My Response:

I think it may be overkill to isolate each customer change request into a separate branch. In addition to the challenge you mention, having to create new build definitions for each branch (which I agree is overkill). The other challenge is the effort to keep your code synchronized. We (VSTS Rangers) recommend building the MAIN branch on a daily basis and  doing frequent merges (FI) from MAIN the DEVELOPMENT branches. Naturally when you have a lot of these branches, this makes the merge effort more time and labor intensive. I would like to understand better what the need for isolating these changes is. On most v-Next development efforts it is not unusual to have a team of developers working on the same feature to be working in the same branch. In our guidance we suggest that every branch comes with a cost and may offer benefits. By understanding the benefits and costs one can make more informed decisions before routinely adding complexity to the branch plan. I would suggest sticking to a simpler model and only adding to the complexity when the benefits outweigh the costs.