Home > Back-end >  Mitigate merge conflicts when pulling branch that has been rebased
Mitigate merge conflicts when pulling branch that has been rebased

Time:09-28

In the course of reviewing PRs, I will pull down a colleague's branch. If my colleague subsequently force pushes changes to remote as a result of a rebase, when I next do a pull, I will get merge conflicts I don't want to deal with - I just want the branch as it exists remotely.

I have been doing:

git checkout master
git branch -D some-branch
git checkout some-branch

That works, but I'm sure there is probably a simpler (and lazier) way to do this.

CodePudding user response:

It's simple: don't pull. Pulling implies that you have a local copy of the colleague's branch. But you don't need one. When you want to review the colleague-branch PR, just say

git fetch
git switch --det origin/colleague-branch

Now you are on the colleague's branch, and you can see the code and run it to test it out.

When the colleague makes a change and you want to see that too, guess what you say?

git fetch
git switch --det origin/colleague-branch

Ta-daaa! You now are on the new version of the colleague's branch. No pull, no merge, no conflicts, no nothing. And no unnecessary local copy that you would just need to delete later.

  •  Tags:  
  • git
  • Related