Git keeping separate branches in sync

Question

I have been working on a branch new_feature:

A -- B -- C -- D    master
      \    \
       \    1 -- 2 -- 3  new_feature
        \
         E -- F -- G  port

Our code base also has an older branch port where another developer ported our product to another RDBMS. port is not yet ready to be merged back into master.

Recently it became necessary to have new_feature work in port. So I merged those two into a new branch port/new_feature, and made some commits there (I, J) to get it working:

A -- B -- C -- D    master
      \    \
       \    1 -- 2 -- 3 -- I* -- J* -- K new_feature
        \              \
         E -- F -- G -- H -- I -- J -- K*  port/new_feature
                  port

I cherry-picked I and J back into new_feature (as I*, J*) because they involved significant refactoring that I wanted to have in new_feature too. I have also been making new commits (K) to new_feature that need to be brought over to port/new_feature (K*).

Going forward, what's the best plan to keep new_feature and port/new_feature in sync (but only with respect to new changes)? Should I keep cherry-picking commits from one to the other (and vice versa)? Or is there a convenient way to do this by merging?

Answer 1

Cherry-picking is dangerous because of:

• duplicate commits (the next merge will be complicated because Git will try to re-apply I-J-K on top of... I-J-K).
  That wouldn't be the case if you rebase one branch on top of the other (see "Git cherry pick and datamodel integrity"), but that isn't possible in your case.

• functional dependencies (see "How to merge a specific commit in git"), but I suspect it isn't an issue in your case: I and J don't depend on H, and can be safely applied to 3.

Cherry-picking is convenient if you don't intend to merge port and new-feature together.
If that is the case, keep cherry-picking.