マージの例マージと比較して、リベースでは、履歴が直線的になり分岐するブランチがありません。このことによる読みやすさは、私がリベースが好きだった理由でした。同じ理由でリベースを好む開発者もいるのではないでしょうか。このアプローチにはいくつかの課題があります。削除された場合を考えてみましょう。リベースされたとき、アプリケーションのビルドは壊れますが、コンフリクトがない限りリベースは中断されません。最初のコミットでエラーが発生しているので、その後のすべてのコミットにおいてもエラーが発生し続けます。適用して修正されます。コンフリクトしているコミットを一時停止し、処理を続行する前にコンフリクトを修正します。コミットが多く連なっている場合、リベース中にコンフリクトを解決することは、しばしば混乱を招き、正しく修正するのが難しく、潜在的なエラーの原因ともなります。エラーの混入は、リベース中に起こった場合、特に問題となります。履歴を書き換えるときに新しいエラーが発生し、履歴が最初に書き込まれたときに混入した真のバグを隠す可能性があります。使うのがより難しくなります。ブランチを考えてみましょう。ブランチの最後の方でバグが混入したとしましょう。マージされてから数週間後まで、このバグに気づかないかもしれません。バグが混入したコミットを見つけるには、数十回または数百回のコミットを検索する必要があります。このプロセスは、バグが混入していないかどうかを確認するスクリプトを書くことにより自動化することができます。コマンドを使うことによりその実行も自動化できます。履歴を二分探索することによりバグが混入したコミットを特定します。以下に示す例では、バグが混入した最初のコミットを見つけることに成功しています。これは、壊れている全てのコミットに、実際に探しているバグが含まれているからです。