24

一部のファイルとディレクトリが削除されたマスターブランチの正確なコピーである特別なブランチ (リリースブランチ) があります。このブランチでは開発は行われていませんが、マスターと同期している必要があるため、マスターの更新は常にそのブランチにプッシュする必要があります。

通常のマージ ( git merge master) を実行すると、常に次のような競合が発生します (サンプルの README ファイルなど)。

CONFLICT (delete/modify): README deleted in HEAD and modified in master

これは予想されることです: 削除したファイルの変更をマージしようとしました。したがって、それらを解決するには、 を使用しますgit rm README。

それを自動化するために、 -X ours を指定することで自動競合解決を使用できると思いました。manページは、それが私にとって正しいことを示唆しています:

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result.

ただし、git merge -s recursive -X ours masterそうすると、同じ未解決の削除/変更の競合が発生します。私は何を間違っていますか？競合解決を自動化する別の方法はありますか?

4

4 に答える 4

20

おそらくこれを行うためのより良い方法がありますが、（デフォルトのマージ戦略で）マージを実行してから実行することで、同様の問題を解決しました

git status | grep 'deleted by us' | awk '{print $4}' | xargs git rm

この後、通常どおり他の競合を解決してからコミットする必要があります。

これは、現在のブランチで削除されたすべてのファイルを削除するだけです。これはあなたが望むものだと思います。

于 2013-12-30T20:14:34.027 に答える
7 
git merge master
git status --porcelain | awk '{if ($1=="DU") print $2}' | xargs git rm
git commit
于 2016-04-07T08:23:23.580 に答える
3

この質問を見ると、私たちの再帰的戦略または彼らのオプションは削除を競合とは見なしていないように見えます。

ただし、この機能を使用して、一部のファイルに特定の戦略を指定することができます。私たちの戦略（オプションではない）がそれらのファイルのトリックを行うことは間違いありません。

編集：

コメントで述べたように、あなたはこれを行うことはできません！

これがあなたにとって非常に重要な機能である場合は、Gitメーリングリストに必ず連絡する必要があります（git@vger.kernel.org） 。

于 2012-07-04T15:36:24.913 に答える
-2

マージの代わりにリベースを使用して、リリース ブランチを実現できます。

于 2012-07-04T17:57:52.110 に答える