CODEWITHSUNDEEP
gitmergerebasegit-rebasemerge-conflict-resolution
B Seven
B Seven

Reputation: 45941

How to resolve git merge/rebase conflicts with 2 remote repos?

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?

Upvotes: 2

Views: 2177

Answers (1)

VonC
VonC

Reputation: 1327584

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

Upvotes: 1

Related Questions