git-rerereとは何ですか？
私が理解したように、これは競合解決情報の保存によるプロジェクトの同期に役立ちますが、それを使用および構成する方法は完全にはわかりません。
継続的インテグレーション（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は次のことを行います。
- 衝突するdiffハンクを（verbとしてのマージがヒットすると）記録します。
- 手動で解決するのを待ちます。
- それらを解決するために何をしたかを（
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を有効にしても意味がありません。なぜあなたはそこにそれを望んでいると思いますか？