6 か月前upgradeに分岐したという分岐があります。masterブランチでは、upgradeすべてのプロジェクトを maven ( masteris ant プロジェクト) に再構築したため、2 つのブランチのプロジェクト x の構造はまったく異なります。
プロジェクトを Maven に再構築するgit mvために使用したので、履歴が保持されます。upgrade次に、アップグレード プロセスでこれらの変更が必要になったため、ファイルのコードを変更しました。
に存在するすべての構造を保持しながら、にマージmasterしたいと思います。どうすればいいですか？upgradeupgrade
枝git merge masterにいながら使ってみました。upgrade
しかし、これは、私たちが行ったコード変更に関する競合を私に与えていませんupgrade。代わりに、プロパティファイルで競合が発生しました。（私は間違いなくupgradeその競合に関するコードの変更を確信してmasterいます） - 何が間違っている可能性がありますか?
あなたが望むのは、ours戦略を使用することです（この回答の以前のバージョンで述べた戦略オプションではありません）。装着したままupgrade、使用してgit merge -s ours masterください。git merge manpageのより詳細な情報によると、これは実際のマージをまったく実行しようとせず、単純に一方のツリーをours結果に使用し、マージの他のすべての側を破棄します。
マージを使用すると、すべての履歴が保持され、マージ コミットが作成されますが (履歴内の 2 つのブランチの収束が示されます)、マージの片側からすべてのファイルが使用されます。
「ours」と「theirs」の意味は、マージを開始したときのブランチに依存するだけであることに注意してください (「merge upgrade into master」と「merge master into upgrade」、どちらも同じ結果の履歴を生成します)。 . merge「私たち」はあなたが立っている1つのブランチであり、「彼ら」はコマンドで指定したブランチです。これについての詳細は、マンページで説明されています。
編集:説明のポイントとして: マスターが共通のコードベースから十分に分岐していないため、(おそらく) コード変更で競合は発生しませんでした。デフォルトでgit mergeは、 は 3 方向マージ戦略を使用します。これは、マージする 2 つのサイドの最新の共通の祖先を取得し、実際にはその共通の祖先に関連する変更のみを調べます。ブランチの片側だけが進行した場合、Git はそこにあるすべての変更が古いコード (あなたの場合は のコードmaster) に取って代わることを認識し、コードを自動的に使用しupgradeます (つまり、「競合」を自動的に解決します)。
手動で解決する必要がある競合は、マージの両側が共通の祖先と比較して変更された場合にのみ発生します。その場合、Git はどちらの側が「優れている」かを認識しません。両方を機能させるには、2 つの側を組み合わせる必要があるかもしれません。そのため、ユーザーはそのような競合を解決するよう求められます。
注: 以前に -s オプションと -X オプションを誤解していたため、回答が更新されました。