Reputation: 423
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?
Upvotes: 0
Views: 107
Reputation: 122024
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:
None of the commits on target_branch
get rewritten, so they retain their original authors; and
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.
Upvotes: 1