How to resolve git merge/rebase conflicts with 2 remote repos?
-
05-07-2021 - |
Pregunta
Having an issue with git rebase conflict, but only when using 2 remote repos. Here's the workflow:
- Do work...
- Commit
- 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.
- 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.)
- git push production
- 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:
- Why do I need to pull from production when I am the only one pushing to it?
- Why are there merge conflicts on code that is already committed and I have not changed?
- Which commit would I choose? HEAD or commit foo
- What is the better process so it doesn't happen?
Solución
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?".