how to easily merge future updates after cherry picking commits. - Or merge a specific commit first?

Question

A particularly nasty bug just happened to our software. (JS/react something was preventing onclick from firing about half the time - turned out a constant rerender was happening). This wasn't really easily to solve and the culprit wasn't found easily. So the way the bug was found was by going back in history till the commit it occurred.

Of course that wasn't a trivial commit, it was a commit containing a big refactoring of code (for those interested, factoring out a few props to contexts and making components more general purpose).

The bug required (as with any complex bug) fixes over multiple files thus wasn't a direct copy paste. After solving the tree looked a bit like this, where the bug occurred between commit A and B:

A - B - C - D - E - F
 \
  A'

With A' containing the "buggy" parts of B but patched. Now the idea is to cherry pick B to see if the fix didn't accidentally break other things in that commit. (instead of directly going to F and having to handle the complexity of all follow up changes).

A - B - C - D - E - F
 \   \
  A'- B'

I resolved the 5ish files that give a conflict between A' and 'B' to create B'. If B' works as expected all changes further on should just work so merging should be easy right?

However when I try to merge F into B' I notice that it gives a lot of conflicts, event more than just merging A', as all files of B' seem to conflict with F, not just the files that are actually different between B' and B, but any file that is changed. (And given the refactoring, that's a lot of files).

Is my better solution to just merge directly from A' into F and hope for the best?

Answer 1

Once you verify B' does indeed fix the bug, you still must deal with the changes introduced by commits C through F. Don't be afraid and overthink this. Merge commits C-F into your branch and see what the conflicts are. If it is too ugly, git reset --hard HEAD and try a different technique. Worse case scenario, create a new branch from your branch just for the merge. That way you can try the merge out, make any number of commits to fix things, and if it goes really sideways, delete the branch.

Once you have confidence you got the merge right, consider rebasing your branch and squashing the commits into one clean commit before merging it into the other branch. A rebase will require you to redo the merges, but now you have experience solving those conflicts.

And lastly, automated testing is your friend here. If you don't have automated tests, it is difficult to gain confidence that your fix doesn't break anything. Git cannot help you with this.