I have a client who insisted that we keep our new development separate from the main branches for the entirety of 2016. They had 3-4 other teams working on the application in various capacities. Numerous large changes have been made (switching how dependency injection is done, cleaning up code with ReSharper, etc). It has now fallen on me to merge main into our new dev branch to prepare to push our changes up the chain.
On my initial merge pull, TFS reported ~6500 files with conflict resolution. Some of these will be easy, but some of them will be much more difficult (specifically some of the javascript, api controllers, and services supporting these controllers).
Is there an approach I can take that will make this easier for me?
To clarify, I expressed much concern with this approach multiple times along the way. The client was and is aware of the difficulties with this. Because they chose to short on QA staff (1 tester for 4 devs, no automated testing, little regression testing), they insisted that we keep our branch isolated from the changes in the main branch under the pretense that this would reduce the need for our tester to know about changes being made elsewhere.
One of the bigger issues here is an upgrade to the angular version and some of the other third party softwares –unfortunately we have no come up with a good way to build this solution until all the pieces are put back into place.
Best Answer
There would have been a simple way which had kept your new development separate from the main branch without bringing you into this unfortunate situation: any change from the trunk should have been merged into your dev branch on a daily basis. (Was your client really so shortsighted that he could not anticipate that your branch needs to be remerged back into the main line some day?)
Anyway, best approach is IMHO trying to redo what should have happened on first hand:
This might work when the teams strictly obeyed to the classic rules of version control ("only commit compilable, tested states" and "check in early and often").
After 365 repetitions (or 250, if you are lucky and you can bundle the work for weekend changes), you will be almost finished (almost, because you need to add the number of changes which will happen to the main line during the integration period). The final step will be to merge the updated dev branch into the trunk again (so you don't loose the trunk's history). This should be easy, because technically it should be only a replacement of the affected files.
And yes, I am serious, there is probably no shortcut to this. It might turn out that "daily portions" might be sometimes too small, but I would not expect this, I guess it is more likely daily portions can turn out beeing too big. I hope your client pays you really well for this, and that this is so expensive for him that he will learn from his failure.
I should add that you can try this also with switched sides - reintegrating the changes from your branch in small portions to the main line. This might be simpler when on your dev branch there were much fewer changes than on the trunk, or most of the changes happened in new source files which are currently not part of the trunk. One can see this as "porting" a feature from a product A (the dev branch) to a somewhat different product B (current state of the trunk). But if the majority of cross-cutting refactorings were done on the main line, and they affect your new code (the 6500 merge collisions seem to be some evidence for this), it might be easier the way I described it first.