I'm failing to understand how to use git-rebase, and I consider the following example.

Let's start a repository in ~/tmp/repo:

$ git init

Then add a file foo

$ echo "hello world" > foo

which is then added and committed:

$ git add foo
$ git commit -m "Added foo"

Next, I started a remote repository. In ~/tmp/bare.git I ran

$ git init --bare

In order to link repo to bare.git I ran

$ git remote add origin ../bare.git/
$ git push --set-upstream origin master

Next, lets branch, add a file and set an upstream for the new branch b1:

$ git checkout -b b1
$ echo "bar" > foo2
$ git add foo2
$ git commit -m "add foo2 in b1"
$ git push --set-upstream origin b1

Now it is time to switch back to master and change something there:

$ echo "change foo" > foo
$ git commit -a -m "changed foo in master"
$ git push

At this point in master the file foo contain changed foo, while in b1 it is still hello world. Finally, I want to sync b1 with the progress made in master.

$ git checkout b1
$ git fetch origin
$ git rebase origin/master

At this point git st returns:

# On branch b1
# Your branch and 'origin/b1' have diverged,
# and have 2 and 1 different commit each, respectively.
#   (use "git pull" to merge the remote branch into yours)
#
nothing to commit, working directory clean

At this point the content of foo in the branch b1 is change foo as well. So what does this warning mean? I expected I should do a git push, git suggests to do git pull... According to this answer, this is more or less it, and in his comment @FrerichRaabe explicitly say that I don't need to do a pull. What's going on here? What is the danger, how should one proceed? How should the history be kept consistent? What is the interplay between the case described above and the following citation:

Do not rebase commits that you have pushed to a public repository.

taken from pro git book.

I guess it is somehow related, and if not I would love to know why. What's the relation between the above scenario and the procedure I described in this post.