私が理解したように、これは競合解決情報の保存によるプロジェクトの同期に役立ちますが、それを使用および構成する方法は完全にはわかりません。
継続的インテグレーション(CI)環境用に構成したい。これを行うことをお勧めしますか?
この他の質問で重複をマークしないでください: git rerereを有効にすることの欠点はありますか? 。私の疑いはとは関係がないので、「rerereを有効にすることの欠点はありますか?それ以外の場合には発生しない可能性のある潜在的な問題は何ですか?」
git rerere
とは何ですか?ドキュメント の注釈のように、rerere
はreusereの略ですコード付きreソリューション。
しかし、それは実際にはそれが何であるかを説明しません。ここで、git rerere
自体(コマンド)を実行する必要がないことを最初に追加しておく価値があります。サブコマンドは、clear
、forget
、diff
、status
、remaining
、およびgc
の6つだけです。これらはどれも解像度を記録または再利用しません。実際、git rerere clear
およびgit rerere forget <path>
は一部の記録された解像度をdiscard破棄します。 gc
コマンドも同様ですが、現在のコマンドではなく古いコマンドを指します。
ほとんどの作業はrerere.enabled
のsettingから行われます(これにより、Gitはgit rerere
を実行しますが、サブコマンドはありません)。適切なタイミングで)。自分でサブコマンドなしでgit rerere
を実行できますが、Gitが独自に実行するため、これは実際には重要なことは何もしません。
git config rerere.enabled true
rerere.enabled
を設定すると、Gitがマージを実行するときに、git am
からのものだけでなく、git rebase
およびgit cherry-pick
やgit merge
などからのマージも実行されます。 ] _自体-競合が発生すると、Gitは次のことを行います。
git commit
に)記録します。ここに欠落しているステップがあります。そのため、2から始まる番号が付けられています。ステップ1は次のとおりです。
記録された解決策が競合を完全に解決した場合、ステップ2〜4は冗長になります。記録された解像度のタイムスタンプを更新するために、Gitはそれらすべてを実行する可能性があります(実行できるかどうかはわかりません)。
rerere.enabled
を設定すると、競合との両方を生成するのは、それ自体をマージすることです(git rerere
が自動的に実行されるため)引数なし)を記録してから、記録されている既存の解像度を再利用しようとします。最終的な解決を記録するのは、それ自体をコミットする行為です(Gitがgit rerere
を自動的に再実行するためです)。したがって、すべて自動です。独自のgit diff
コマンドを実行して、以前に再利用された解像度が正しいことを確認する必要があります。そうでない場合は、ファイルを修正し、通常どおりに追加してコミットすると、Gitは記録された解像度を新しい解像度に置き換えます。
ただし、git add
およびgit commit
!常にマージ結果を検査(および/またはテストを実行)する必要があります—ただし、rerere.enabled
の設定に関係なく、常に実行する必要があります。
VonCがコメントで指摘 のように、以前に記録しなかった既存のマージ競合解決がある場合は、それらの解決でrerereデータベースを「トレーニング」できます。 これを行うためにGitソースに提供されたスクリプトがあります。オンラインでも利用できます。
CI環境では最初にマージの競合を解決してはならないため、CI環境でrerere
を有効にしても意味がありません。なぜあなたはそこにそれを望んでいると思いますか?