git-merge のマニュアル ページには、使用できるマージ戦略がいくつか記載されています。
解決- これは、3 方向マージ アルゴリズムを使用して、2 つのヘッド (つまり、現在のブランチとプル元の別のブランチ) のみを解決できます。交差するマージの曖昧さを慎重に検出しようとし、一般的に安全で高速であると考えられています。
recursive - これは、3 方向マージ アルゴリズムを使用して 2 つのヘッドのみを解決できます。3 方向マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージされたツリーを作成し、それを 3 方向マージの参照ツリーとして使用します。Linux 2.6 カーネル開発履歴から取得した実際のマージ コミットで行われたテストでは、これにより、マージの競合が少なくなり、マージの失敗が起こらないことが報告されています。さらに、名前の変更を伴うマージを検出して処理することもできます。これは、1 つのブランチをプルまたはマージする場合のデフォルトのマージ戦略です。
octopus - これは 2 つ以上のヘッドのケースを解決しますが、手動で解決する必要がある複雑なマージは行いません。これは主にトピック ブランチ ヘッドをまとめるために使用されます。これは、複数のブランチをプルまたはマージする場合のデフォルトのマージ戦略です。
ours - 任意の数のヘッドを解決しますが、マージの結果は常に現在のブランチ ヘッドになります。これは、サイド ブランチの古い開発履歴を置き換えるために使用することを目的としています。
サブツリー- これは修正された再帰戦略です。ツリー A と B をマージするときに、B が A のサブツリーに対応する場合、同じレベルのツリーを読み取るのではなく、まず B が A のツリー構造と一致するように調整されます。この調整は、共通の祖先ツリーに対しても行われます。
デフォルトとは異なる設定を指定する必要がある場合はいつですか? それぞれどのようなシナリオに最適ですか?
ベストアンサー1
私はresolveについてはよく知りませんが、他のものは使用しました:
再帰的
再帰は、非高速順方向マージのデフォルトです。これは誰もがよく知っていることです。
タコ
私は、複数のツリーをマージする必要がある場合に Octopus を使用しました。これは、多数のブランチが個別に開発され、すべてが 1 つのヘッドにまとめられる準備ができている大規模なプロジェクトで見られます。
タコ ブランチは、きれいに実行できる限り、複数のヘッドを 1 つのコミットにマージします。
たとえば、マスターがあり、それをマージする 3 つのブランチ (a、b、c と呼びます) があるプロジェクトがあるとします。
一連の再帰マージは次のようになります (再帰を強制しなかったため、最初のマージは早送りであったことに注意してください)。
ただし、単一のタコのマージは次のようになります。
commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...
私たちのもの
私たちの == 別のヘッドをプルインしたいのですが、そのヘッドが導入するすべての変更を破棄します。
これにより、ブランチの影響を一切受けずにブランチの履歴が保持されます。
(注意: これらのブランチ間の変更は確認されません。ブランチは単にマージされ、ファイルには何も行われません。他のブランチにマージしたい場合、そのたびに「私たちのファイル バージョンか、それとも彼らのバージョンか」という質問が表示されるので、 を使用できますgit merge -X ours。)
サブツリー
サブツリーは、現在のプロジェクトのサブディレクトリに別のプロジェクトをマージする場合に便利です。サブモジュールとして含めたくないライブラリがある場合に便利です。