Keeping Fork in sync

[David Welsh]

Hey,

We recently have decided to fork several of our repos since one team (Team A) is heading in one direction and another team (Team B) is heading in a different direction.

So we are going to leave team A using the original repo (Repo A) and create a fork of it called Repo B for Team B. So far this is simple but we want Team B to be able to get updates from Repo A and push them into Repo B.

Ideally what we would want would be to grab Master from Repo A and merge it into a Feature Branch in Repo B so we could test the changes before they make there way for master. (Master in Repo B would also continue to have its own updates that were never part of Repo A).

What would the easiest way to do this be? It looks like in stash I can do pull requests from Repo A Master to Any Branch in Repo B. But would this continue to work from 30, 60, 90 days? I know the more regular the merges are from A -> B the easier they would be.

But here is an example: 30 days from the fork, Repo A has had 100 new commits on master and Repo B has had 50 new commits on Master and I want to get the 100 from Repo A onto a update branch in Repo B. I would create the pull request but I assume I would get merge conflicts, so how I would go about merging it then since its cross repo? (I'm new to pull requests)

EDIT: Thinking about this, I could create a master-a branch in the B Repo that I could keep doing regular pull requests from Repo A master -> Repo B master-a which should never have conflicts since I'd lock it to read only except for those pull requests. Then I could just merge master-a in Repo B to my update branch and I'd be on my way. Would that work?

[David Welsh · Accepted solution]

Doing what is in my edit works just fine for what I'm looking to accomplish.

[cofarrell]

Hi David,

Managing multiple branches is one of those tricky problems that will never have an ideal solution.

In addition to your edit, I just wanted to suggest that you try to keep the two branches as up-to-date as possible. You should be almost be merging daily, and you could even set up a CI build to do that automatically and email the teams if that fails.

In an ideal world it's better not to have long-lived branches at all, and instead keep the work in the same code base and use flags or other mechanisms to enable certain features. Over time your two branches are going to diverge to the point where it becomes harder and harder to fix the merge conflicts. Alternatively is there a common 'library' that both teams can share and then two 'applications' can be implemented in isolation without any need to merge at all?

Don't mind me I'm just making suggestions from the backseat. :)

Best of luck.

Charles

[David Welsh]

Hi Charles,

We realize this isn't an ideal solution, the original plan was to utilize flags and other mechanisms in order to have our application switch between runmodes however that didn't go according to plan...

We entered a blitz in order to meet a client deadline which resulted in flags not being utilized, unique work arounds being implemented since the data backing the application (Third Party Data) was coming in different than expected and a host of other issues.

This caused merging repo B back into repo A a large effort which would require doing an audit to make sure things got moved back to being toggled based off the run mode of the application. Additionally there would need to be a large amount of testing to ensure nothing broke, while trying to maintain active development with our weekly release cycle.

I don't foresee the master-a branch being used in repo-b since we already tried to do a merge but had conflicts with several large projects on repo-a that occured after we forked.

I hope we can keep refactor and re-do certain functionality to move of it into shared components making maintenance even easier, but who knows.

Cheers,

David