My usual way of dealing with merge conflicts in pull requests is to check out the target_branch and pull from the repo. Then merge the target_branch into my feature_branch. Now I have the conflicts on my feature_branch ready to be resolved, but I also have every other change pushed to the target_branch as well.

Is there an approach that only fetches the changes causing conflicts, so that I do not rewrite the history on my colleagues commits?

1 Answers

jonrsharpe On Best Solutions

Typically the way I'd address this is with a rebase. Assuming you're starting with something like:

target_branch  ...--A---B---C---D---E
feature_branch            F---G

Then the following:

git checkout feature_branch
git rebase target_branch

Will result in the following:

target_branch  ...--A---B---C---D---E
feature_branch                        F'--G'

This has two useful properties for you:

  1. None of the commits on target_branch get rewritten, so they retain their original authors; and

  2. The rewriting of first F (becoming F', with a new parent E instead of B) then G (becoming G', with a new parent F' instead of F) allows you to resolve any conflicts with C, D and E stepwise.

The result is a pair of commits on feature_branch that can easily be applied back to target_branch without conflicts.

Note that if you've already pushed feature_branch to the remote, the rewriting of history means that you'll have to force push (ideally --force-with-lease) these new commits.