How to handle rebasing after base branch has been merged?

Question

I was developing a feature branch (A) based off another feature branch (B), and now the branch I was developing off of (B) has been merged to master.

Git now sees A as being in conflict with master because I have the changes from B, but so does master because B was merged. I am therefore unable to merge A. Merging master into A makes no difference.

How can this situation be resolved? Rebasing onto master leads to a lot of manual conflict resolution. My branch (A) does not change any files that are changed in master; all the conflicts result from A including B's changes, which are already in master.

Answer 1

Usually what you want to do in this case is to use git rebase --onto . This lets you specify both the original base branch and the new one. So you'd do something like this:

$ git checkout A
$ git rebase --onto master B

This treats the original base branch as B and places the commits on top of that on master instead. Usually Git will detect this case automatically and a normal rebase will work, although it will fail in some cases, notably if you do a squash merge.

Answer 2

Another option, if you are confident that all of the conflicts are due to A including B's changes, is a merge using the recursive strategy with ours option:

From the docs:

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.