Difference between git pull --rebase, git rebase and git merge

Question

Could anyone explain this with keeping even the remote repositories in mind?

Answer 1

git pull --rebase is the way to go when you want to bring your development branch up to date - those branches are usually not published to others (except maybe for having a look at it) so rewriting history is not a problem and you really don't want merges etc in such a branch.

git merge performs a merge; see the manpage for details - the comand has tons of options which would be too much to explain here.

git rebase performs a rebase, i.e. it rewrites history. It will take your commits up to the point where they diverge from the other branch, remove them temporarily, apply the missing commits from the other branch and then re-apply your commits. git rebase also has an interactive mode where you can remove/modify/combine(squash) certain commits.

Have a look at http://learn.github.com/p/rebasing.html for some nice graphs on how rebases work.

Answer 2

git rebase allows you to detach a branch from the point it has diverged, and re-plug it on top of the other branch. git merge is instead simply merging the changes from another branch in the current branch, without history re-plugging.

If there are no conflicts, the result is identical between merge and rebase, but the history is different:

(merge branch on master):
master    --A--B--C--E
                   /
branch          --D

(rebase branch onto master):
master     --A--B--C--D'

In first case the merge creates the branch branch is merged into master, leading to creation of a merge commit, E. In the second case, D is simply re-plugged onto master, creating anther commit, D'.

git pull --rebase will fetch the changes from a remote, and rebase (re-plug) your changes on top of it. It will literally record the changes you made that are not on the remote, and replay them starting from the last change that it just fetched.