2

I have a repo where i have two main branches (one is a custom version of the standard product and the other is the standard). They share like 90-95% of the code, but there are vital differences on them.

What is the best way to create new features that i can merge into both those branches?

Up until now i have started a new branches from one or the other of the main branches and then cherry picked into the other...but it's starting to be a pain. And the git tree looks like sh!t :(

If i merge the branches the receiving branch will be corrupted and have a ton of conflicts, so that is why i have been using cherry-pick.

Is there a nice workflow for something like this? There must be a better way. The reason i have the two main branches is because almost all of the code are identical, but there are minor,but significant, differences between the main branches.

merger
  • 698
  • 1
  • 10
  • 28
  • Are these branches meant to be merged again at some future point? – Romain Valeri Mar 05 '20 at 14:16
  • Most likely no. They will almost certainly have some differences. – merger Mar 05 '20 at 14:22
  • 1
    It really sounds like figuring out how to handle the variant withing single branch would be something worth striving for. I.e. handle the difference with build time configuration for instance. – Ondrej K. Mar 06 '20 at 18:19

1 Answers1

1

Pretend for a second that one permanent branch is “newer” than the other—like a new-features branch F vs. a bug-fix branch B. (If one of your branches has more unique code than the other, call it F for this purpose to minimize the need for merging in both directions.) Then, if a change applied to both, it would by definition be a bug fix, so you would apply it to B and later merge B into F, resolving any conflicts that arose because the new features changed the relevant code.

This model works here as well (especially if almost all new changes apply to both versions and can be made on B first), but there’s a problem: the first time you merge, you’ll attempt to bring all the unwanted differences between F and B into F. So make a fake merge first: merge B into F but don’t actually change F at all. Then only new work on B (i.e., the very “new features” you asked about) are eligible for being merged, which is what you want.

The fake merge can be created as follows (using only cross-platform shell features):

# create cmt with a message for the fake merge
git commit-tree F: -p F -p B <cmt
# use the hash it prints below
git checkout F
git merge $HASH

The merge will be a fast-forward because the commit-tree was based on F.

Davis Herring
  • 36,443
  • 4
  • 48
  • 76
  • This sounds interesting! But i dont understand it =) I will have to do some testing to see what happens. – merger Mar 07 '20 at 10:54