2016-04-13 16 views
0

'残っているすべてのマージの競合について'、マージ競合の解決として '私たち'を選択する方法はありますか? 私の場合、「私たち」も削除であり編集ではありません。残っているマージの競合を、削除されたファイルの 'ours'として解決します。

私はGit Extensionsを使用していますが、少しコマンドラインで作業しています。 マージを行うと、マージを解決するために一連の複雑なプロセスが進行します。 1つのプロセスでは、私のブランチ上で私はそれらを削除しているので、常にマージで競合するファイルのセットが存在します。

通常、コンフリクトがあることを確認してから、リポジトリから特定のファイルを削除し、コンフリクトのあった他のファイルを適切にマージします。

私のローカルファイルシステムが正しいと確信したら、私はGit Extensionsに行き、すべてのマージされた競合ファイルに対してマージを選択し、 'ours'(Deleted)...を1つずつ選択しました....(Git Extensionsでは複数選択できません)。 ファイルがたくさんあるので、他のマージをやり終えたら、残っているすべてのマージ競合に対して、一括して 'Merge - > Ours'を実行できる方法を探しています。

+0

--oursフラグがあります。 http://gitready.com/advanced/2009/02/25/keep-either-file-in-merge-conflicts.html – pedrorijo91

+0

を確認してください。そうですね、これを一括して行うようにしています... -file ....私はすべてのマージのために約200ファイルのためにそれを行う必要があるので。 –

答えて

0

私はGUIでこれを行う方法の見当がつかないが、コマンドラインで:

git checkout HEAD -- path1 path2 path3 path4 ... 

( "私たち" バージョンをとる)または:

git checkout MERGE_HEAD -- path1 path2 path3 path4 ... 

(とり"theirs"バージョン)。

「私たち」バージョンの場合は、ちょうど、(あなたの説明のように)欠失である:にインデックスを設定するには

git rm path1 path2 ... 

「の解像度は、ファイルを削除することです」。


編集は(2つのコメントの後に)追加します。git checkout --oursgit checkout --theirsgit checkout HEADgit checkout MERGE_HEADの代わりに使用することができます。違いは1つあります。競合するマージの途中にある場合、インデックスには、競合があるpathのステージングスロット1,2、および/または3のエントリが含まれています。コンフリクトしていないパスの場合、インデックスにはステージゼロのエントリしかありません。指定されたは(コミットに関連付けられた木から、より正確に)をコミットからHEADまたはMERGE_HEADからチェックアウトすると、ファイルを抽出しながら、エントリを上演--ours--theirs抽出してチェックアウト。

ステージ1のエントリはマージベース、ステージ2は--ours、ステージ3は--theirsです。競合が変更されている場合は、3つのステージングスロットがすべて使用されます。競合がdelete-vs-modifyの場合、ステージングスロット1は使用されていますが、残りのスロットの1つは使用されていません。競合がcreate-vs-createの場合、スロット1とスロット2は空になり、スロット2と3が設定されます。

git rmまたはgit checkoutを実行すると、競合ステージングスロットがクリアされ、通常のステージ0エントリに解決結果が取り込まれます。 Gitは、矛盾したステージが残っていない場合にのみ、最後のマージコミットを許可します(git ls-files --stageはステージ0以外は何も表示しません)。

GUIを嫌う多くの理由の1つは、インデックスの再チェックを拒否し、ベストが何であるかを知っていると考えているからです。あなたのようなものであれば、それを解決するすべてのCLIを無視し、すべての解決がGUI自体を通過する必要があります。

+0

私はあなたのようなgit checkout --oursや他のメソッドの言及を見ましたが、それらはすべて事前マージです(私は信じています...)。 -fact(コミットする直前)、私は '私たちとの残りのすべての矛盾を解決したい(私の場合は削除)'したい。私はあなたの答えを試してきました、そして、それはこれをやっていないようです。 –

+0

これはすべて、中途半端なマージ( '--no-commit'とのマージまたは衝突の後)で行われます。私はそれをやったことがあります(ただし、CLIだけですが)。変更または削除された競合の場合、 'git rm --cached'だけでなく' git rm'が必要です。作業ツリーにはファイルのバージョン( 'HEAD'または' MERGE_HEAD')が保持されているためです。何らかのGUIがこれを許可しない場合、GUIは何か間違っている(例えば、必要に応じてインデックスを再読み込みしない)。 – torek

関連する問題