私がそうgit rebase branch1するとき、branch1-local私は衝突します。競合を解決し、実行しgit add <conflicted-add>てgit rebase --continueから、git が要求するとおりに実行します。その後、新しいコミットが適用されます。新しい競合が表示されます。しかし、同じファイルで再び同じ競合です。git add、 、をもう一度実行しgit rebase --continue、リベースする各コミットに対してこれを繰り返すまで、すべてを繰り返します。
リベースによって、同じ競合解決を何度もやり直さなければならないのはなぜですか?
必要なのはgit rerere、競合の解決を記録するものです。これについて私が見た中で最も優れた紹介は、Git Book のツールの章の一部です。実際には、リベースを実行すると、以前と同じように停止することになりますが、マージの競合が解決されたままであることを確認してgit addから続行するだけで済みます。
同じ競合が何度も発生するべきではありません。Rerere はここでは役に立ちません。これは単に、コミットをリプレイしようとしているコードベースが非常に異なるため、各コミットを調整するためにあなたの助けが必要であることを意味します。これが、リベースよりもマージを優先する理由の 1 つです。私の意見では、リベースは必要な場合にのみ使用し、通常のワークフローの一部ではありません。Rerere は、マージ/リセット タイプのワークフローでさらに役立ちます。リベースを回避するワークフローは次のとおりです。 http://dymitruk.com/blog/2012/02/05/branch-per-feature/
この問題を軽減する 1 つの方法は、Beyond Compare のようなスマートなマージ プログラムを使用することです。これは構文を認識しており、Git が (正当に) 拒否するかなりの数の競合を解決します。多くの場合、これらのツールは、呼び出されたときに UI を開くことさえせず、問題を解決して、git mergetoolコマンドが次の競合に進むことを許可します。「mergetool 終了コードを信頼する」を true に設定することを忘れないでください。