What's the difference between `git fetch` then `git rebase`, and `git pull --rebase`?

Question

In reading the git pull page, it gives this stern warning about git pull --rebase:

This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.

In the git rebase page, it gives a lot of description but no warning of this sort.

In addition, I've seen some people say that

git fetch git rebase 

is the same as

git pull --rebase 

while others say they're slightly different.

What's the truth?

Answer 1

The truth is that they ARE different. Here's a really helpful web page which explains it beautifully:

http://gitolite.com/git-pull--rebase.html

So git pull --rebase has some significant magic over git fetch; git rebase which most of the time you won't notice, but in cases where the upstream maintainer has naughtily ignored all those stern warnings and decided to rewrite the history of a public branch, it can really help out by consulting your local reflog and doing the local rebase in a more intelligent way.

That said, this is still a rebase, so you are still rewriting history! Therefore all the standard stern warnings still apply. But if you're working on a private (i.e. unpublished) branch, then that's OK.

I'll say a bit more regarding the stern warnings. They are valid, but personally I find most people just a bit too paranoid about rebase, like a git rebase crept into their bedroom in the middle of the night when they were young and ate their sister or something. It really shouldn't be that scary:

• if it's a private branch, rebase to your heart's content
• if it's a public branch don't rebase unless you really have to, and if you do, make sure you understand the impact, and make sure anyone who might be impacted is properly informed about what you've done, so they don't get a nasty surprise and waste a load of time figuring out what happened.

It's that simple. And yes, I would go as far as actively encouraging people to regularly git rebase -i on their private branches. Polishing history before pushing to somewhere public/upstream is a good thing, because no one wants to wade through a project's history which is full of commits like 'oops, fixing a mistake I made 3 commits ago'. (OTOH, don't get totally obsessed with rebasing in quest of a flawless history. We're human. We make mistakes. Deal with it.)

One last observation regarding the git pull --rebase magic. If the upstream public branch has been rebased in a sensible way (e.g. squashing / fixing up commits, or dropping commits which shouldn't have been put there) then the magic works in your favour. However if the upstream rebase accidentally dropped commits, then the magic will silently prevent you from putting them back. In this case if you want to put back those dropped commits, you should instead use git fetch; git rebase.

Answer 2

The rule with Git is that you should never attempt to change history after it has been shared, published, or pushed. You can do so, of course, if you really want to and have sufficient permissions, but it should be done with great care since it can mess other people up.

Now fortunately when you have a typical Git deployment with a single upstream repository (origin) which is the source of all that is good and true in the universe, you can use git pull --rebase to your heart's content and it will be perfectly safe and in my opinion give you a much more sane (meaning linear) history. I and my team use it continuously.

However, if you start having multiple remotes and start doing git pull --rebase <arguments> so that you are no longer rebasing against the same target every time, or start pushing your branch to alternate repositories before running git pull --rebase with your primary upstream—then you can start running into troubles.

Any time where you share your changes with another remote/repository and then change those changes (for values of changing equal to changing the SHA, parent, etc. even if the commit message/content did not change), you can mess up the person who had the old changes.

As long as you don't fall outside the envelope of rebase sanity, git pull --rebase will be very good for you.

That, err, doesn't answer the question about the difference between git pull --rebase and git fetch && git rebase @{u}. I'll just go ahead and say that I am unaware of any difference and if there is one, it is subtle enough that I have not noticed it in the years I have used Git. Possibly in that the system figures out the correct repository your branch should fetch if you have multiple repositories and "origin" isn't the upstream of this branch?

And even if you do go very awry with git-rebase, you can of course recover yourself back to your original pre-rebase environment easily with git log -g and/or git reset --hard ORIG_HEAD. Just don't do force pushes (disallowed by default in almost all Git servers), and you will be happy happy.

EDITED

With time my understanding has expanded. git pull --rebase calls git rebase to do the rebase work, so in that sense there is no difference between them. However, git-pull actually calls git rebase --onto @{u} $(git merge-base HEAD @{u}@{1})

OK, that syntax ("@{u}@{1}") is perhaps a little opaque and is a simplification to boot, but the point is that it finds out what the merge base was to upstream BEFORE it ran the fetch command. What difference does this make, you ask?

Well, in the normal case none. However, if you are changing where upstream is pointing to or if upstream itself was rebased, quite a lot. If upstream was rewritten and then you did a git rebase @{u} you could be very unhappy and could get double-commits or conflicts depending on how much the older commits were rewritten.

However, with the magic behind git pull --rebase only the commits which are yours and yours alone will be applied on top of @{u}.

OK, this too is a simplification. If upstream did a rebase starting with the 100 commits ago (but there are actually 101+ commits in history) and you did a git fetch before doing a git pull --rebase then Git will not be able to accurately determine what the proper historical merge-base was to figure out what your local commits are.

The upshot of which is, git fetch is considered harmful (when you have local commits and upstream is rewritten). However, the real rule-of-thumb is "never attempt to change history after it has been shared, published, or pushed" which is where I started.

TL;DR:

git fetch is considered harmful (so use git pull --rebase); and never attempt to change history after it has been shared, published, or pushed (because, among other things, it will cause git fetch to be harmful).