ブランチの履歴を書き換えることによって生じる主な問題はマージに関する ことです。誰かがあなたのブランチをフェッチし、自分のブランチにマージ すると、結果は次のようになります：

 o--o--O--o--o--o <-- origin
        \        \
         t--t--t--m <-- their branch:

そして、最後の３つのコミットを修正したとします：

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin

もしそれらが１つのリポジトリに入っていたとすると、 次のようになります：

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin
        \        \
         t--t--t--m <-- their branch:

Git は新しい head が古い head の更新されたバージョンであることを認識 しません；Git はこのような状態を２つの開発者が古い head と新しい head で 並行に作業したものとして扱います。 その為、だれかが当たらし head を自身のブランチにマージしようとすると、 git は old を new に置き換える代わりに、その２つの開発ライン(old と new) をいっしょにマージしようとします。 その結果は、期待したものとはことなります。

履歴が再編集されたブランチをまだ公開しようとするかもしれません。 そして、それらブランチをフェッチし順番にテストするのは役に立つことだと 思うかもしれません。しかし、そのようなブランチを自分の作業エリアに pull すべきではありません。

適切なマージをサポートする本来の分散開発では、 公開されたブランチは決して再編集されるべきではありません。