341

Another question says that git pull is like a git fetch + git merge.

But what is the difference between git pull and git fetch + git rebase?

Improve this question
3
  • 2
    someone should clean up the link... and I'm amazed at how many votes that other question got. Commented Jul 28, 2010 at 20:33
  • 13
    @xeno: I think its just a count of how many people go "I had this question too" Commented Jul 28, 2010 at 21:10
  • 61
    Some day I'll find time to really read the git documentation, but until then, I'm adding my votes to these types of questions Commented Sep 18, 2012 at 16:03

2 Answers 2

Reset to default
380

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 - H - 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 - H - 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 - H - 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 had committed on top of origin's new master branch (R), instead of where you originally committed (H). 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.

Improve this answer
Sign up to request clarification or add additional context in comments.

16 Comments

What happens if you were to rebase after someone had already pulled from your master branch? Would that break the repo?
How do you know if someone has pulled from your master branch?
If you don't know for sure that someone hasn't, you should assume that they have.
I was just thinking that unless you're also pushing changes somewhere other than origin/master, I don't see ever running into the problem of someone else having pulled the changes in question, because if you had already pushed these changes to origin/master, there would be nothing to rebase in the first place. It seems to me that the warning really only matters in cases of where you've got something more complex than X -> origin/X, but I could be wrong. If someone knows of a scenario I'm overlooking, please share.
@SteveChambers No, that's not the result. The lines simply represent commit ancestry, i.e. A is the parent of B. There's not any implication about whether Q or B was first in time. All these operations are based on commit graphs, not time. Rebase simply transplants some commits, with the result as I showed no matter what the commit timestamps are.
|
34

TLDR:

git pull is like running git fetch then git merge
git pull --rebase is like git fetch then git rebase

In reply to your first statement,

git pull is like a git fetch + git merge.

"In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD" More precisely, git pull runs git fetch with the given parameters and then calls git merge to merge the retrieved branch heads into the current branch"

(Ref: https://git-scm.com/docs/git-pull)


For your second statement/question:

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

Again, from same source:
git pull --rebase

"With --rebase, it runs git rebase instead of git merge."


Now, if you wanted to ask

'the difference between merge and rebase'

that is answered here too:
https://git-scm.com/book/en/v2/Git-Branching-Rebasing
(the difference between altering the way version history is recorded)

Improve this answer

3 Comments

I'd like to mention that "git pull --rebase" is like "git fetch then git rebase" most of the time - but not always. In some situations, "git pull --rebase" does a bit more. See this often referenced example here: gitolite.com/git-pull--rebase
Thank you so much for your answer. I really understand the way git fetch + git rebase commands work from now. There's no more or less conflict on our git tree from now :)
@DanielK, git rebase also does those additional steps, since shortly after that blog post was written. See the discussion of --fork-point in git help rebase.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.