gitを使用して共有フォークリポジトリを更新する

私が正しく理解していれば、次のような単一の（ローカル）リポジトリがあります。

            A/master
               ↓
* -- * -- * -- a
                \
                 * -- * -- b
                           ↑
                       B/mybranch

さて、A更新されたので、次のようになります。

                          A/master
                              ↓
* -- * -- * -- a -- * -- * -- a+
                \
                 * -- * -- b
                           ↑
                       B/mybranch

ここで、直線上にない2つの分岐した分岐があることに注意してください。ですから、a+ b aマージAしたときに得られると言うのBは正しくありません。あなたはマージを取得しますが、それは履歴をそのまま保持します：

                          A/master
                              ↓
* -- * -- * -- a -- * -- * -- a+
                \               \
                 * -- * -- b --- M
                                 ↑
                            B/mybranch

あなたが見ることができるように、あなたはまだコミットがどこから来た情報があります間のものをaし、a+一方のブランチから来た、と他のものの間aおよびb他から来ました。そしてM、それらのトロブランチを組み合わせます。通常、これはまさにこれを解決するための適切な方法です。

リベースに対するこれの利点は、あなたが気付いたように、コミットが現状のままであるということです。いずれかのリポジトリを操作したすべてのユーザーは、問題なくそれらの変更を取り込むことができます。これらのコミットのいずれかをリベースした場合、手動で修正する必要があります（おそらく、それを認識していないため、コミットが重複していると、プルして実際にはさらに厄介な履歴が作成されます）。

したがって、ここでマージを行う方が間違いなく優れています。はい、履歴は直線ほど完璧には見えませんが、何が起こったかを適切に伝えますA。独立した分岐した開発ラインがあり、アップストリームリポジトリからの変更で更新されています。この情報は役立つ可能性があるため、それらを保持することは理にかなっています。特に、ユーザーが両方のリモートと対話している場合、ユーザーはリポジトリを両方のリモートと互換性を保つことを確実に好みます。

履歴をこのように見せたくない場合、およびとの互換性を気にしないA場合は、すべての変更をからAに押しつぶすこともできますB。

                          A/master
                              ↓
* -- * -- * -- a -- * -- * -- a+
                \
                 * -- * -- b -- [A]
                                 ↑
                            B/mybranch

ここでは、[A]間のすべての変更が含まれているコミット潰れるaとa+、単一ではコミット。あなたはリベースすることによって、この結果を得ることができるA上にB、すべてのコミットを押しつぶしながら。この場合、これらの変更がどこから来たのかをコミットメッセージに明確に記載する必要があります。