Git bi-directional merging

Question

I'm wanting to know the best approach for dealing with this git scenario:

Git repo a: CoreProduct

Git repo b: SpecificCustomerProduct which was forked from a

Up until now, we have been making different changes to both a and b, and only merging a down to b. All good so far - the specific product is gaining features from our CorePoduct

Now, we have ended up with some commits in b, that we would like to get back up into a (and there is new stuff in a that also needs to come down to b as usual)

Question: What is the best way to get these specific commits from b up to a, with the intent of keeping our more regular merges from a to b as painless as possible moving forward?

Question: If we were doing this from scratch, how would you do it?

I was thinking of cherrypicking commits from b into a temp branch on b and then 'pull request' that branch up to a, but am concerned about that affecting future merges from a to b..

Answer 1

Suppose your repo has such a structure:

... --- A1(branch_A)
         \
          \
... ------ B1(branch_B)

My suggestion is:

(1) Just in case, backup your branches first by git branch bak_A branch_A and git branch bak_B branch_B.

(2) git checkout branch_A, do the modifications (by cherry-picking or by merging, whatever you want) then commit, you will get a A2 like this (the edge between B1 and A2 may not exists, and it doesn't matter):

... --- A1 --- A2(branch_A)
         \    /
          \  /
... ------ B1(branch_B)

(3) git checkout branch_B, then git commit-tree branch_B^{tree} -p branch_B -p branch_A -m "<commit messages>" | xargs -I {} git merge {}, you will get:

... --- A1 --- A2(branch_A)
         \    / \
          \  /   \
... ------ B1 --- B2(branch_B)

in which B1 and B2 have the same content.

(4) Now you can continue your development as before. If anything goes wrong, you can restore your branches by git branch -f branch_A bak_A and git branch -f branch_B bak_B.

Answer 2

For keeping things in the future as painless as possible make sure that B is up to date with the changes from a via merge or rebase and then do the process in reverse unto A. cherry-pick is not a good idea as that creates a new commit sha that won't be shared in the histories and could cause trouble down the road.

Doing a merge from B to A is the simplest way and will keep things easy going forward. The history will show the commit coming from B and it shouldn't cause any problems.