ProGit book には 良い説明 があります。
あなたの質問に対する具体的な答えは、「The Reils of Rebasing」というタイトルのセクションにあります。そのセクションからの引用：
ものをリベースすると、既存のコミットを放棄し、類似しているが異なるコミットを作成しています。コミットをどこかにプッシュし、他の人がそれらをプルダウンして作業をベースにした後、それらのコミットをgit rebaseで書き換えて再度プッシュすると、共同作業者は作業を再マージする必要があり、あなたがしようとすると物事が面倒になります彼らの仕事をあなたのものに引き戻します。
更新：
以下のコメントに基づくと、Gitのワークフローに問題があるようです。役立つ参考資料を次に示します。
gitworkflowsmanページ：「上向きにマージ」および「トピックブランチ」を参照- ProGit：「 Private Managed Team 」を参照してください
- Jarrod Spillersブログ：「 git merge vs git rebase：Revoid Hellの回避 」を参照してください
これを理解するには、gitの動作について少し理解する必要があります。 gitリポジトリはツリー構造であり、ツリーのノードはコミットです。非常にシンプルなリポジトリの例を次に示します。 
マスターブランチに4つのコミットがあり、各コミットにはID（この場合、a、b、c、およびd）があります。 dは現在、masterブランチの最新のコミット（またはHEAD）であることがわかります。 
ここには、masterとmy-branchという2つのブランチがあります。 masterとmy-branchの両方にコミットaとbが含まれていることがわかりますが、それらは分岐し始めます。masterにはcとdが含まれ、my-branchにはeとfが含まれます。 bは、マスターと比較した場合のmy-branchの「マージベース」、またはより一般的には「ベース」と呼ばれます。理にかなっています。my-branchは以前のバージョンのmasterに基づいていたことがわかります。
それで、私のブランチが古くなったとしましょう、そしてあなたはマスターの最新バージョンでそれを最新にしたいと思います。別の言い方をすれば、my-branchはcとdを含む必要があります。マージを行うこともできますが、それによりブランチに奇妙なマージコミットが含まれることになり、プルリクエストのレビューがはるかに困難になります。代わりに、リベースを行うことができます。
リベースすると、gitはブランチのベース（この場合はb）を見つけ、そのベースとHEAD（この場合はeとf））の間のすべてのコミットを見つけ、これらのコミットを、リベースするブランチ（この場合はマスター）のHEADで再生します。Gitは、変更がマスターの上にどのように見えるかを表す新しいコミットを実際に作成します。図では、これらのコミットはe 'およびf'と呼ばれます。Gitは以前のコミットを消去しません。eおよびfはそのまま残されます。リベースで何か問題が発生した場合は、以前の状態に戻ることができます。
多くのさまざまな人々がプロジェクトに模擬的に取り組んでいる場合、プルリクエストはすぐに古くなる可能性があります。 「古い」プルリクエストとは、開発のメインラインで最新ではないものであり、プロジェクトにマージする前に更新する必要があります。プルリクエストが古くなる最も一般的な理由は、競合によるものです。2つのプルリクエストが同じファイル内の同様の行を変更し、1つのプルリクエストがマージされると、マージされていないプルリクエストが競合します。場合によっては、プルリクエストが競合せずに古くなる可能性があります。おそらく、コードベース内の別のファイルを変更するには、新しいアーキテクチャに準拠するためにプルリクエストに対応する変更が必要になるか、失敗した単体テストを誰かが誤ってマージしたときにブランチが作成された可能性がありますマスターブランチ。理由に関係なく、プルリクエストが古くなった場合、マージする前にブランチをマスターブランチの最新バージョンにリベースする必要があります。
リベースは履歴を書き換えます。誰もその歴史を知らないなら、それはまったく問題ありません。ただし、その歴史が公に知られている場合、Gitで歴史を書き換えることは現実の世界と同じように機能します。陰謀が必要です。
陰謀は実際に一緒に頑張るので、そもそも公的なブランチのリベースを避ける方が良いでしょう。
are成功した陰謀の例があることに注意してください：Junio C. Hamanoのgitリポジトリ（Git SCMの公式リポジトリ）のpuブランチは頻繁にリベースされます。これが機能する方法は、puを使用するほとんどすべての人がGit開発者のメーリングリストにも登録されており、puブランチがリベースされているという事実はメーリングリストとGitで広く公開されているウェブサイト。
リベースは、リポジトリの履歴を変更します。コミットを世界にプッシュする、つまり他の人が利用できるようにしてから、コミット履歴の表示を変更すると、古い履歴を持つ人と作業することが難しくなります。
Rebaseは有害と見なされます は良い概要です。