Question

Having an issue with git rebase conflict, but only when using 2 remote repos. Here’s the workflow:

1. Do work…
2. Commit
3. pull -r staging master

This works fine. If there is a conflict I can resolve it.

Then the problem happens when working with production remote repo. I am the only one pushing to production.

1. git pull -r production (need to do this before pushing to production for some reason…don’t know why because it should be a fast forward push.)
2. git push production
3. git pull -r staging (to update my repo)

Here’s where I get all sorts of merge conflicts on files I haven’t worked on.

The conflict may look like this:

<<<<<<< HEAD
  here's some code...
=======
  more code...
>>>>>>> commit foo

So, here are the questions:

1. Why do I need to pull from production when I am the only one pushing to it?
2. Why are there merge conflicts on code that is already committed and I have not changed?
3. Which commit would I choose? HEAD or commit foo
4. What is the better process so it doesn’t happen?

Answer 1

That is a direct side-effect of your pull --rebase done for two separate remote repos: you are rebasing existing local commits on top of a remote HEAD you just fetch, making sure to create a new HEAD SHA1 which wouldn’t exist on your second remote repo (prod for instance)

You can use pull --rebase for commits you have never pushed anywhere, as detailed in “When should I use git pull –rebase?“, when collaborating on the same branch of the same remote repo.

But when you have 2 remotes repos, you should avoid it after the first push, as illustrated in “When will git pull --rebase get me in to trouble?“.

Even more details on that topic at “What git branching models actually work?“.