Branching for a Patch in Team Foundation Server 2012

Question

I'll preface this question with the statement that we are likely using TFS incorrectly based on some early misunderstandings on how TFS works, versus how GIT works.

Background:

• We have a main branch which is where we do all of our development.
• When we are ready to release, we create a branch off of the main branch and name it by the version (ex, "v8.10.0").
• We compile and release from this new branch.
• We then proceed with development back on the main branch.
• If a critical issue is discovered with the previous release, and we are mid-stream in a sprint on the development branch, then we need to create a patch for the previous version. In this case, we create a new branch off of the release branch and start fixing the problem on that new branch (ex "v8.10.1").
• Then we want to get the fix(es) we applied on the 8.10.1 branch into the main branch, and so we perform a merge from 8.10.1 to dev, and that is where the problems start to happen. This merge is a baseless merge and without fail that merge takes hours to complete, involves a lot of manual merging, and at the end of the process there are usually a handful of files that got botched in the merge process. Even worse, TFS usually decides that it can auto-merge some of the files and it tends to do this completely wrong and we wind up with completely ruined code.

There seems to be a flaw in our basic understanding of how to accomplish this task, and though it does not happen often, it always bites us, so what are we missing, and what is the correct way to do what I have outlined above?

Answer 1

Well there are many strategies of branching and only you can decide which is most suitable for you. What I see from the question is that you have main development branch and release branches. You have no branch for testing. You have no branches for parallel development. You have branches for hotfixes. One way to organize branches is:

O----------------main dev branch------------------>
    |                                             ^
    V                                             |
    O---------------release branch---------------->
         |                                        ^
         V                                        |
         O--------------hotfix branch------------->

So you have 1 branch for main work in development. Branch for realese from main(one branch not per release). And branch for hotfix from release. For versioning you can apply labling on release branch( https://msdn.microsoft.com/en-us/library/ms181439.aspx ). Now you can merge without problems from main to release, from release to hotfix and back from hotfix to realese and from release to main.

In reality things get a little complicated with testing branch and parallel development branches. In my project we use something like this:

O--------parallel dev2---------------------------->
^                                                 |
|                                                 V
|    O---parallel dev1---------------------------->
|    ^                                            |
|    |                                            V
O------------------main dev branch---------------->
     |                                            ^
     V                                            |
     O--------------test branch------------------->
         |                                        ^
         V                                        |
         O--------------relese branch------------->

But without all this, your design should also work. The main reason you have problems is that you are doing a baseless merge when you could merge hotfix branch back to release branch and from release back to main branch.