Why is it safe to rebase under these conditions?

Question

The git documentation mentions in several places not to rebase if the code has been pushed to a public repository. However, I have seen this rebase strategy suggested in multiple places while Googling my Git problems.

The situation stated is to use git pull with the --rebase option when working with other devs in order to reduce the amount of merge commits which "pollute the logs". This can even be made automatic by setting the branch.master.rebase option to true.

Why is this strategy considered safe, seeing how the fine documentation specifically warns against rebasing when working with other devs?

Answer 1

I believe you're misinterpreting the warning.

Say there's a local commit A that hasn't been pushed, and a commit B that hasn't been pulled. By running git pull --rebase, you're gonna destroy commit A, pull commit B, and re-create commit A on top of B.

Since commit A is local, this is fine and safe, and it's what the rebase strategy suggests. But, the documentation tells you not to do this if commit A had already been pushed (to a different branch, for example). In that case, you'd be destroying a publicly available commit, and re-writing public history.

Answer 2

When you do a git pull --rebase you don't push anything anywhere. So it's safe.

With a normal git pull, the following happens:

A-B-C(master)
   \
    D(origin/master)

becomes

A-B-C-E(master)
   \ /
    D(origin/master)

Which is "polluted" with a merge commit.

If you use git pull --rebase instead:

A-B-C(master)
   \
    D(origin/master)

becomes

A-B-D(origin/master)
     \
      E(master)

No merge, more linear history. Still no push, no danger. You've only rewritten the history of your local master branch.

The very reason that master and origin/master have diverged, is that you have not pushed your master yet. That's why there is no contradiction with all the warnings about using rebase.