Let's say you have these Git repositories:
- your private repo, sitting on your work computer;
- your public repo,
you, hosted somewhere;
- a main repo,
origin, which is the main development tree.
You're working on something and made two commits A and B. You published them to your public repo. In the same time, origin has one other commit Z.
/-A-B master, you/master
o-o-o
\-Z origin/master
Now let's say one colleague needs your two commits to begin a new feature. He pulls your branch from your public repo and makes some commits on top of that.
/-C-D-E colleague/master
/-A-B master, you/master
o-o-o
\-Z origin/master
You now want to add your two, completely tested, commits on top of origin/master. You fetch from origin and make a rebase (which is equivalent to git pull --rebase or git pull with the pull.rebase option set).
That creates two new commits. You push them to your public repo and to origin. To complicate things further, let's say a new commit F is pushed to origin after that.
/-A-B-C-D-E colleague/master
o-o-o
\-Z-A'-B'-F master, you/master, origin/master
Now the problem is that your colleague has some work based on two "deprecated" commits, and to avoid further complications (conflicts when merging, messing up history) he must rebase his branch on top of B' (let's say he doesn't want F). You need to tell him about that, or else maybe he won't notice what you've done.
/-C-D-E colleague/master
o-o-o-Z-A'-B'-F master, you/master, origin/master
If you didn't tell him, later he would merge his branch back into origin, and the history would look like this:
/-A-B-C-D-E
o-o-o \
\-Z-A'-B'-F-M colleague/master, origin/master
You have twice the A and B commits, though with different names. The history becomes harder to read, and you will run into awful merging conflicts. And remember this example is quite simple. If there are tens of people working on the project, and origin is moving fast, the history will soon become a complete mess.
If it's only one colleague it's probably fine. But if you can't know exactly who pulled from you, you can't know who you have to warn. It's especially true in open source development.
The main rule is: don't rebase commits you've already published. If A and B were only in your private repo, rebasing is fine and is probably the best thing to do, because it makes the history simpler and meaningful. A diverging history is only meaningful when the branch has a good reason to exist (e.g. a feature branch).
