There is a way to reparent an existing branch to an integration branch, but to do what you are asking is very tricky. The built-in reparent feature is not intended for this scenario. You may not like this solution much. If you fear this scenario,
then make your integration branch at the beginning.
So I tried an experiment. You can experiment too. Here is what I did:
I Created Dev1, Dev2, Dev3 off of Main.
Then I "decided" to create an integration branch off of Main.
I then created Dev1new and Dev3new off of Main.
I then checked out Dev1, Dev3, Dev1new, Dev3new.
I then copied the old Dev1 folder over Dev1new.
I then copied the old Dev3 folder over Dev3new.
I then checked in the Dev1new and Dev3new.
I then undid checkout on Dev1 and Dev3.
I then deleted Dev1 and Dev3 as I no longer needed them.
In summary,
I created the new branching structure I desired.
I checked out every project involved in the reorganization (both old and new
Using windows explorer, I then copied the old project files over the new ones.
I verified it all worked.
I checked in the new projects (that are now off the Integration branch).
I undid checkout on the old projects as they were the source and did not get altered. The only reason I checked them out in the first place was to remove the read-only locks on them so that when they were dropped over checked out files, they would
be in the same state as the files they replaced.
As you can see, this is possible. I figured did the whole demo in 15. But it is not pretty. It is so complex that there is a risk you will make a mistake. You can also use baseless merges instead, but I am unfamiliar with them in practice and
cannot give any advice on their value.
And lets keep this in perspective. You would do all this just to reduce the risk that your Dev1 and Dev3 teams would not step on each other when they merge their changes in the common code module? The safer thing is to have a single sub-team responsible
for changing the common sub-module on behalf of both other teams. Or, you could leave Dev1, Dev2, and Dev3 branches as they are. Then, the first one(let's assume the Dev1 team) who checks in their tested code has it easy. The second team (Dev2) is responsible
for getting the latest version, merging from Main to Dev2, then ensuring all tests pass before checking it in.
If the separate projects are so different or mutually dependent on one another that they really NEED an integration branch, this should be obvious from the very beginning. And thus, you can design an integration branch from the start.
Sorry for the complicated answer. But branching cannot magically solve all problems of development. All the pieces are interrelated - the branching approach, the environments available, the way the teams are organized, the way the work is organized,
the nature of the changes made, etc...
