1

Say I have these following release branches: r1, r2, r3 and the master branch, with r1 being the oldest. After implementing a bugfix in r1, I normally would do the following sequence of merges:

r1 -> r2 -> r3 -> master

If this certain bugfix is only relevant for the older releases r1 and r2, then I would merge with the "ours" strategy in r2 -> r3.

My problem now is, what if, say, only r2 doesn't need this bugfix, while it is still relevant for r3 and master? If I would do the merge in the "ours" strategy in r1 -> r2, then r3 and master will not receive the bugfix. Straight forward solutions I can come up with would make the commit history kinda messy. What is the cleanest way to merge down from r1 to master while keeping the history clean?

A more general question would be: If I have an arbitrary amount of release branches to merge and some of them do not need the bugfix, how to do it correctly?

Thanks!

SmilingMan
  • 33
  • 1
  • 5
  • `cherry-pick` is probably more suitable for moving changes between release branches, or any situation where you need to be surgical. – jingx Jun 04 '18 at 17:04
  • @jingx thanks for your comment. `cherry-pick` is definitely one solution. Right now I also think that this is the best solution, as long as there is no need to merge between branches motivated by other circumstances. But I'm still concern about problems that "copied commits" can cause in certain situations. – SmilingMan Jun 05 '18 at 16:08

0 Answers0