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?
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.
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.
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).