Reputation: 103
I have a setup where I code on my local
machine and pull it from my dev
box to test it.
Say I create a commit A
on branch foo
on local
, and create a branch foo
on dev box which has upstream set as local/foo
. If I do a git pull
from branch foo
on dev box, branch tree of dev/foo
becomes same as local/foo
.
But if I now amend the commit A
in local/foo
, git pull
from branch foo
on dev box gives a merge conflict. Whereas git pull --rebase
works correctly and does not dupicate commit A
twice on dev/foo
.
git help pull
says that:
-r, --rebase[=false|true|merges|preserve|interactive]
When true, rebase the current branch on top of the upstream branch after
fetching. If there is a remote-tracking branch corresponding to the upstream branch
and the upstream branch was rebased since last fetched, the rebase uses that
information to avoid rebasing non-local changes.
I get that the last line is being applied in the above scenario, but I don't understand what the pre-conditions are or how its working?
An explanation would be very helpful. Thanks
Upvotes: 5
Views: 5684
Reputation: 55483
This is because of the difference of merging and rebasing.
"Regular" git pull
first fetches the changes and then
merges them into the local state, while git pull --rebase
fetches the changes and then rebases the local state on top
of the remote's.
Merging considers only the two states of the project—the "ours" and "thiers" side of the merge, plus, when possible, the so-called "merge-base" of them—the last common commit these lines of development shared.
Rebasing, on the contrary, first resets the "ours" side to point to the same commit the "theirs" side has at its tip and then applies each "ours" commit "theirs" does not have individually—as textual patches, one-by-one.
This may have a greater chance of not producing conflicts as the local changes are re-applied onto the remote's updated state incrementally.
Upvotes: 7