How does `git pull --rebase` correctly pull amended commits?

Question

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

Answer 1

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.