あるブランチの変更を別のブランチに統合するための方法が大きく分けて二つあります。このセクションでは、リベースについて「どういう意味か」「どのように行うのか」「なぜそんなにもすばらしいのか」「どんなときに使うのか」を説明します。振り返ってみましょう。作業が二つに分岐しており、それぞれのブランチに対してコミットされていることがわかります。コマンドを使うことです。分岐した作業履歴をひとつに統合するしかし、別の方法もあります。先端に適用するのです。コマンドを使用すると、一方のブランチにコミットされたすべての変更をもう一方のブランチで再現することができます。今回の例では、次のように実行します。取得して一時ファイルに保存し、現在のブランチの指す先をリベース先のブランチと同じコミットに移動させ、そして先ほどの変更を順に適用していきます。マージができるようになりました。指すスナップショットと全く同じものになりました。最終的な統合結果には差がありませんが、リベースのほうがよりすっきりした歴史になります。リベース後のブランチのログを見ると、まるで一直線の歴史のように見えます。平行稼働していたにもかかわらず、それが一連の作業として見えるようになるのです。リモートブランチ上での自分のコミットをすっきりさせるために、よくこの作業を行います。自分がメンテナンスしているのではないプロジェクトに対して貢献したいと考えている場合などです。リベースすることになります。するだけで済ませられるのです。あなたが最後に行ったコミットが指すスナップショットは、リベースした結果の最後のコミットであってもマージ後の最終のコミットであっても同じものとなることに注意しましょう。違ってくるのは、そこに至る歴史だけです。リベースは、一方のラインの作業内容をもう一方のラインに順に適用しますが、マージの場合はそれぞれの最終地点を統合します。興味深いリベースリベース先のブランチ以外でもそのリベースを再現することができます。ような歴史を考えてみましょう。作成してサーバー側の機能をプロジェクトに追加し、それをコミットしました。切って数回コミットしました。ブランチに戻ってさらに何度かコミットを行いました。トピックブランチからさらにトピックブランチを作成した歴史クライアント側の変更を本流にマージしてリリースしたいけれど、サーバー側の変更はまだそのままテストを続けたいという状況になったとします。オプションを使用します。上でそれを適用しろ」という意味になります。複雑ですが、その結果は非常にクールです。ブランチのほうも取り込む準備ができました。実行するだけでだいじょうぶです。