Git pull rebase - What is it rebasing

Question

I still don't get what exactly happens with git pull --rebase. I understand the rebasing concept and I have used it in my own local unpublished branch, never when my branch is already published in the remote. I've heard the dangers of doing a rebase with remote, and looking at git pull --rebase, I don't quite grasp how this is safe or when it is unsafe to do so.

Say for example I am working on MyBranch branch and have been pushing it to the remote so that it gets stored somewhere else other than my own local machine (and probably other people will merge my changes to keep development in sync).

a--b--c--d--g--h (master, origin/master)
      \
       e--f--i (MyBranch, origin/MyBranch)

Say I do some local development

a--b--c--d--g--h (master, origin/master)
      \
       e--f--i (origin/MyBranch)--j--k--l (MyBranch)

Say someone else updates MyBranch with the development that has gone into master.

 a--b--c--d--g--h (master, origin/master)
       \         \
        e--f--i---m( origin/MyBranch)
               \
                j--k--l(MyBranch)

If I then update by pulling git pull --rebase, how would my tree looks like? Will it only rewrite the history of j, k, l (those local to mine) and put it on top of m, or will it rewrite other history that is already on the remote branch?

What exactly is the rebase start point and which is the replays?

Also if origin/MyBranch is being merged into other upstream branch like "develop" then what are the implications of my rebase?

a--b--c--d--g--h (master, origin/master) --n --o --p (origin/develop)
      \         \                                 /
       e--f--i---m( origin/MyBranch)--------------
              \
               j--k--l(MyBranch)

Answer 1

A commented, git pull --rebase is:

• git fetch: here your remote tracking branch origin/MyBranch has been updated)

  a--b--c--d--g--h (master, origin/master)
         \         \
          e--f--i---m( origin/MyBranch)
                 \
                  j--k--l(MyBranch)
  

• git rebase: you rebase MyBranch on top of origin/MyBranch

  a--b--c--d--g--h (master, origin/master)
         \         \
          e--f--i---m( origin/MyBranch)
                     \
                      j'--k'--l'(MyBranch)
  

Answer 2

I use rebase all the time on my local work. The worst problem I have experienced is I merged wrong. Using git reflog I reverted to my last commit and rebased again until I got it right.

There are a few situations that come to mind for when not to rebase or be cautious if you feel you must.

1. The repo is used by more than one person, but is not the "blessed" repo. Anytime a repo is shared it is almost always bad to alter history. With that said, if everyone agrees, pushes their current work, you rebase, and they reset their HEAD (As well as other similar strategies) it could be done without heartache.
2. Two branches have a divergent but similar codebase (a fork, like macosx / freebsd). In that case it would almost assuredly be a bad idea to rebase osx.
3. You have literally thousands of commits since you diverged. When using git reflog to fix your mistakes, it's important to know that git's cache of old commits is finite. Given enough local commits, a rebase could leave you unable to revert to your pre-rebase commit.

That last point bit me once. I also tend to use git rebase -i a lot. I had about 200 commits and was carefully reordering, grouping, and squashing commits with a goal of getting down to maybe 10 commits.

A week or so later I realized there was a problem and wanted to compare with the old stuff. I tried reflog but the oldest commit was in the middle of my rebasing. I got lucky and found a clone I had made, but after that I learned to be more careful with rebase.