git pull VS git fetch git rebase

Question

Another question on git pull and git fetch said 'git pull is like a 'git fetch + git merge'.

But what is the different between git pull VS 'git fetch + git rebase'?

Thank you.

Answer 1

git pull --rebase is the equivalent to git fetch && git rebase

Answer 2

It should be pretty obvious from your question that you're actually just asking about the difference between git merge and git rebase.

So let's suppose you're in the common case - you've done some work on your master branch, and you pull from origin's, which also has done some work. After the fetch, things look like this:

- o - o - o - o - A - B - C (master)
               \
                P - Q - R (origin/master)

If you merge at this point (the default behavior of git pull), assuming there aren't any conflicts, you end up with this:

- o - o - o - o - A - B - C - X (master)
               \             /
                P - Q - R --- (origin/master)

If on the other hand you did the appropriate rebase, you'd end up with this:

- o - o - o - o - P - Q - R - A - B - C (master)
                          (
                          (origin/master)

The content of your work tree should end up the same in both cases; you've just created a different history leading up to it. The rebase rewrites your history, making it look as if you'd committed on top of origin's new master branch, instead of where you originally committed. You should never use the rebase approach if someone else has already pulled from your master branch.

Finally, note that you can actually set up git pull for a given branch to use rebase instead of merge by setting the config parameter branch.<name>.rebase to true. You can also do this for a single pull using git pull --rebase.

Answer 3

for starters if you want git fetch && git rebase do git pull --rebase which does exactly the same thing.

You have to understand what rebase does. Effectively what rebase will do is rewrite your history and place any patches you have that aren't in that history on top of it.

A merge will not rewrite your history, if it is not a fast-forward it will end up making a new commit to resolve the merge.