異なるgitマージ戦略をいつ使用しますか？

git-mergeのmanページから、いくつかのマージ戦略を使用できます。

• resolve -3ウェイマージアルゴリズムを使用して解決できるのは、2つのヘッド（つまり、現在のブランチとプルした別のブランチ）だけです。それは交差交差のあいまいさを注意深く検出することを試み、一般に安全かつ高速であると考えられています。

• 再帰的 -これは、3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3ウェイマージに使用できる共通の祖先が複数ある場合は、共通の祖先のマージされたツリーを作成し、それを3ウェイマージの参照ツリーとして使用します。これにより、Linux 2.6カーネル開発履歴から取得された実際のマージコミットに対して行われたテストで、マージのミスを引き起こさずにマージの競合が減少すると報告されています。さらに、名前の変更を伴うマージを検出して処理できます。これは、1つのブランチをプルまたはマージするときのデフォルトのマージ戦略です。

• タコ -これは2頭以上のケースを解決しますが、手動での解決が必要な複雑なマージを拒否します。これは主に、トピックのブランチヘッドをまとめるために使用することを目的としています。これは、複数のブランチをプルまたはマージするときのデフォルトのマージ戦略です。

• 私たち -これは任意の数のヘッドを解決しますが、マージの結果は常に現在のブランチヘッドになります。これは、サイドブランチの古い開発履歴に取って代わるために使用されることを意図しています。

• サブツリー -これは修正された再帰戦略です。ツリーAとBをマージするとき、BがAのサブツリーに対応する場合、Bは、同じレベルでツリーを読み取るのではなく、最初にAのツリー構造に一致するように調整されます。この調整は、共通の祖先ツリーに対しても行われます。

デフォルトとは異なるものをいつ指定する必要がありますか？それぞれに最適なシナリオは何ですか？

私はresolveについては詳しくありませんが、他のものを使用しました：

再帰的

再帰は、非早送りマージのデフォルトです。私たちは皆、それをよく知っています。

たこ

マージする必要のあるいくつかのツリーがあるとき、私はタコを使用しました。これは、多くのブランチが独立した開発を行っており、すべてをまとめて1つのヘッドにする準備ができている、より大きなプロジェクトで見られます。

タコのブランチは、きれいにできる限り、1つのコミットで複数のヘッドをマージします。

例として、マスターがあり、マージする3つのブランチ（a、b、cと呼ぶ）があるプロジェクトがあるとします。

一連の再帰的マージは次のようになります（最初のマージは再帰を強制しなかったため、早送りであったことに注意してください）。

ただし、1つのタコのマージは次のようになります。

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

私たちのもの

私たちの==私は別の頭を引き出したいのですが、頭がもたらすすべての変更を捨てます。

これにより、ブランチの影響なしにブランチの履歴が保持されます。

（読み取り：これらのブランチ間の変更も調べられません。ブランチはマージされ、ファイルには何も行われません。他のブランチにマージしたい場合、「ファイルバージョンまたはバージョン」を使用できますgit merge -X ours）

サブツリー

サブツリーは、別のプロジェクトを現在のプロジェクトのサブディレクトリにマージする場合に役立ちます。サブモジュールとして含めたくないライブラリがある場合に役立ちます。

実際にあなたが選択したいと思う唯一の2つの戦略がある私たちは、あなたが枝によってもたらされた変化を放棄するが、歴史の中で枝を維持したい場合、およびサブツリーあなたは「gitの-guiの」 'のように（親プロジェクトのサブディレクトリに独立したプロジェクトをマージしている場合git 'リポジトリ）。

タコのマージは、3つ以上のブランチをマージするときに自動的に使用されます。 resolveは主に歴史的な理由と、再帰的なマージ戦略のコーナーケースに遭遇した場合のためにここにあります。

「解決」対「再帰」マージ戦略

再帰は現在のデフォルトの2ヘッド戦略ですが、検索を行った後、ようやく「解決」マージ戦略に関する情報を見つけました。

O'Reillyの書籍「Version Control with Git（Amazon）」から抜粋（言い換え）：

当初、「解決」はGitマージのデフォルトの戦略でした。

可能性のあるマージ基準が2つ以上あるような、クロスクロスマージの状況では、解決戦略は次のように機能します。考えられるマージベースの1つを選択し、最良のものを期待します。これは実際には思ったほど悪くはありません。多くの場合、ユーザーがコードのさまざまな部分で作業していることがわかります。その場合、Gitは既に行われている変更を再マージしていることを検出し、重複を回避して競合を回避します。または、これらが競合の原因となるわずかな変更である場合、少なくとも競合は開発者が処理しやすいはずです。

デフォルトの再帰戦略で失敗した「解決」を使用してツリーを正常にマージしました。fatal: git write-tree failed to write a treeエラーが発生しました。このブログ投稿（ミラー）のおかげで、「-s resolve」を試してみましたが、うまくいきました。理由はまだ正確にはわかりませんが、両方のツリーで重複した変更があり、それらを適切に「スキップ」して解決したためだと思います。

上記の回答はすべての戦略の詳細を示しているわけではありません。例えば、いくつかの答えは、インポートの詳細は不足しているresolveオプションをし、recursive多くのサブオプションを持っているとしてours、theirs、patience、renormalize、など

したがって、gitすべての可能な機能の機能を説明している公式ドキュメントにアクセスすることをお勧めします。

https://git-scm.com/docs/merge-strategies