I have a variety of suggestions. I hope that some of them will be useful.
First, I recommend that you carefully study the TFS_Branching_Guide_Scenarios_2010_v1.pdf, and in particular the first two scenarios (development and hotfix etc...) Although they may not look exactly like the standard branch plan, they provide additional
explanation for the most common scenarios used in all of the branch plans. In other words, think of the branching guide scenarios as a shared and reusable reference that provides additional clarity for all of the branch plans. For example, the first scenario,"Scenario
#1: Single Team Branching Model ", can provide insight regardless of whether you chose the basic, standard, advanced, or mature branch plans as described in "TFS_Branching_Guide_Main_2010_v1.pdf." That scenario teaches you some of the mechanics
of how to handle development activities. Likewise, the second scenario, describes a variety of hot fix and release related activity.
You have successfully understood several of the ideas found in the branching guidance. But I sense that you need to play with it a little bit and get more comfortable with how the concepts translate into the mechanics. I strongly recommend that you set up
a sandbox team project working project collection, put a copy of your solution in it, and experiment with the branching plan of your choice. Then you can test some of YOUR scenarios, and then document for yourself the preferred rules for forward and reverse
integration. This lack of experience is one of the greatest impediments for people who are just getting started with branching. But of course, if you don't have experience, how do you get started? The answer is that you play - you experiment. Once somebody
suggests it, it seems really simple. But many people forget to create a sandbox and play. They think that they have to pick the perfect branch plan and put it into production immediately even though they don't have any experience with branching plans. Of course
you're anxious if you're contemplating that approach. Your anxiety will go away if you do some experiments. One of the things that will happen if you do experiments is that you will train yourself how to do branching properly and you will reduce the chance
that you will make mistakes. The other thing you'll discover is that it is very unlikely that you will back yourself into a corner and create a mess if you pick one of the branch plans recommended by the ALM Rangers in the branching guidance.
That is how I learned to understand the branching guidance. I read it several times and I got some of the ideas, but it just didn't fully fit together until I played with the branching tools and walked through various scenarios. The beauty of the sandbox
is that you can try out a large number of widely varying scenarios without any risk or discomfort. So you can conduct a large number of experiments in a very quick amount of time.
When I work with teams that need a branch plan, I take the PowerPoint slide deck provided in the branching guidance package. It is named TFS Branching Guide - Diagrams 2010_20100330.pptx. Then I use the graphics to create my own branch plan and I create
my own scenarios, complete with written rules. For example, you could have a scenario that describes what people are supposed to do when they start development, and a different scenario for what to do when the software is ready to release. You could provide
a different scenario that describes branching merges or rollbacks that were needed if somebody comes up with a feature that gets all the way to user acceptance testing and has to be removed.
On a slightly different topic, you may also be hampered by a misconception that the selection and design of a branching plan is a simple algorithmic task. It is not. Designing your own branching plan is a lot more of a heuristic activity. My point here is
that you will not find a written instruction that tells you step-by-step what to do to fit your situation perfectly. Instead, you will have to design your own branching plan, modeled after existing ones, and adapted using the rules of guidance. What you do
is start with one of the plans listed in the guidance. The standard branch plan seems like a perfectly good place for you to start. Then you study the scenarios and you play with them in your sandbox. But you play with them in a very scientific way. You take
each of those scenarios that you describe in your earlier post, and you perform a simulation to see how you would handle it. For example, you wrote of a scenario where
"some features will go all the way to UAT and then won't pass and we will probably need to roll-back changesets in Main branch because the release date cannot be pushed further because of other 10 urgent features"
If you are really concerned about that scenario, test it out in your sandbox. If you can figure out how to use branching to solve your problem, it will reassure you that the branch plan you have tested will work for you in this situation.
What you may find it is that trying to use branching to solve a problem with the broken development process is not the best solution. It would be better to figure out how a feature gets all the way to user acceptance testing and instead of fixing it, you
decide to deferr it to a future release. That sounds really bad to me. The problems with that feature should have been found and fixed much sooner in the process when there was plenty of time to get it done correctly. To be more precise, the testers should
have been collaborating with the developers much earlier in the development process. Or, what is the point in having a user acceptance testing activity if you are not going to allow for time to repair the defects? I know this happens far too often. But it
is ridiculous. I mean, you have to keep in mind, that if you rollback a change set, you may affect shared code that breaks other things and you will have to rerun all the regression tests in every other area. So rolling back the change set may be more dangerous
than leaving the broken feature in the build in planning and emergency hot fix soon after the release. If you are going to ignore problems with personnel and process like this, and hope to use branching to mitigate the problem, I fear you are going to be disappointed
with the final result. But I want to reiterate that the ideal agile approach would be to make sure that features that reach user acceptance testing should rarely have showstopping defects that cannot be repaired in a timely manner.
I apologize if it seems that I was getting hung up on that one example that you gave. But it illustrated a really good point that I have seen arise in this discussion forum again and again. In some cases, people try to design the branching plan to mitigate
problems that should really be solved in some other way. Since we are talking about heuristics, the rule would read something like this
"If you have an unusual problem situation and you think you need a special branch to fix it, before you design and implement that branch, consider other ways you could solve that problem without using branching. Then choose the
solution that makes the most sense."
In one situation you may find that branching techniques are the answer. In another situation, you may prefer that design you proposed that involves configuration switches which can turn the unapproved features off. And finally, there may be situations in
which somebody needs to change the people are policies to prevent a recurrence of this unfortunate situation.