2

My small group of developers creates and maintains interfaces to several different versions of our company's core product. The different versions of our core product are mostly similar, but there are some differences which require us to keep our code in a separate branch for each version. Everything is in the same repository.

We were recently required to switch to Git, and are trying to determine the best workflow for when we need to make the same change to all of our branches. Thus far, we have been relying on Cherry Pick for every commit. It is cumbersome and there has to be a better way.

Here is an example of what we're doing:

V1 Master:  ... (A1)--(B1)--(C1)---------(M)
                              \          /
V1 Feature:                    (D)----(E)
                                      /
V2 Master:  ... (A2)--(B2)--(C2)  <--?

Before merging our V1 feature onto V1 master, we rebase onto V1 master. This is simple and makes sense since V1 Feature was branched off V1 Master. However, now we want those same D and E commits applied to V2 Master. The branches are similar enough that those commits shouldn't cause conflicts. Right now we just Cherry Pick them individually, and in order.

I have been searching around and I can't figure out the best way to go about this, because Cherry Pick can't be the proper way to do it.

hurlman
  • 366
  • 3
  • 6
  • Possible duplicate of [Manage multiple git release branches for multiple customers](https://stackoverflow.com/questions/39035631/manage-multiple-git-release-branches-for-multiple-customers) – max630 Aug 25 '17 at 07:41

1 Answers1

1

Note: your schema does not illustrate a rebase, but a merge.

And cherry-picking works for multiple commits in one command.
It is a good solution, provided the branch from which you are cherry-picking (masterV1) will never be merged to the cherry-picking destination branch (masterv2)

That is because cherry-pick duplicates a commit.
And you need to be sure the commits you are cherry-picking have no functional dependencies based on previous commits (of the source branch).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250