2

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?
B Seven
  • 44,484
  • 66
  • 240
  • 385
  • 1
    A reason I can think that would require a `pull --rebase` is that you are changing the history on **staging** that was already pushed. (Through `merge`'s or `rebase`'s, for example). Remember those change the checksum's of your commits and then git can't make a fast forward. – madth3 Oct 05 '12 at 01:17

1 Answers1

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?".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So I should do `git pull` without rebase on the production repo? – B Seven Oct 06 '12 at 02:33
  • 1
    @BSeven that would be better: in general, `pull --rebase` only if what you are rebasing (your local commits) haven't been already pushed (anywhere) – VonC Oct 06 '12 at 06:35
  • `git pull` didn't work. There was a bunch of conflicts. I guess `git push -f` is the only solution... – B Seven Oct 09 '12 at 22:03
  • 1
    @BSeven in the state you currently are, one push - fill could indeed be necessary. However, if you stop using rebases, you shouldn't have that many conflicts in the future, and will avoid any forced push. – VonC Oct 10 '12 at 04:43