With respect to Team Project organization, the VS ALM Rangers are publishing an article in MSDN Magazine on this topic (Feb 2011 issue).
In our branching guidance, we create a Main branch for stabilizing the next release. After this is stabilized we branch main for release, and lock the release branch down. It seems you are using Main the way we recommend using the Release branch. And then
it seems you are adding a new branch for UAT and QA. This what Main is used for in our Guidance.
There are a couple of key points here. I do not recommend creating a branch for testing that is owned by QA. The development team should own the Main and Development branches. If QA needs to start testing... I recommned you deploy code to QA (not branch
for QA). By this, I mean you would either build Main and deploy to QA or build a dev branch and deploy to QA.
The QA, since they do not understand the code, should not be responsible for merging. Merging should be owned by the development team - people that know the code and can best resolve merge conflicts. Further, the decision when to do a merge should be made
by the Dev Team. The Dev team may look for QA to certify the code, that is passes the QA quality gates, but then the Dev team should do the merges.
I think this approach would mitigate the issues where QA needs to bring in the Developer to resolve merge conflicts. QA should never being doing the merges in the first place.
In our model, your QA456 branch would be Main. This is the branch for stabilizing code. When QA wants a new build... build Main and deploy a new build to QA.
If you want to test a single Dev branch independently of other Dev branches, build that branch and deploy to QA.
Having a QA branch AND a Dev branch for every Dev Team simply increases the merge effort and merge conflicts by an order of magnitude.
Deploy a branch to QA, fix the bug in the branch that is deployed for testing. If the bug is fixed in Main, do regular merging from Main to each of its children Dev branches.
If a bug is fixed in Dev, it will get merged to Main when the decision is made that the Dev branch is ready to be integrated, shared, or released. This prevents Main from becoming destabilized.
I recommend not giving merge permissions to QA at all, and not giving merge permissions to every developer. You should designate technical leads or senior developers and give them merge permisssion.
VS ALM Ranger