プル中の変更を優先してGitマージの競合を解決する

プルされた変更を優先してgitマージの競合を解決するにはどうすればよいですか？

基本的に、競合のgit mergetoolないすべての変更を保持しながら、すべての競合を通過する必要なく、すべての競合する変更を作業ツリーから削除する必要があります。できれば、後でではなく引っ張っているときにこれを実行します。

git pull -s recursive -X theirs <remoterepo or other repo>

または、単に、デフォルトのリポジトリの場合：

git pull -X theirs

すでに競合状態にある場合...

git checkout --theirs path/to/file

再帰的な "theirs"戦略オプションを使用できます。

git merge --strategy-option theirs

男から：

ours
    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.

    This should not be confused with the ours merge strategy, which does 
    not even look at what the other tree contains at all. It discards 
    everything the other tree did, declaring our history contains all that
    happened in it.

theirs
    This is opposite of ours.

注：manページが言うように、「私たち」のマージ戦略オプションは、「私たち」マージとは非常に異なっている戦略。

すでに競合状態にあり、それらすべてを受け入れるだけの場合：

git checkout --theirs .
git add .

反対のことをしたい場合：

git checkout --ours .
git add .

これはかなり抜本的ですので、実行する前に、このようにすべてを完全に消去したいことを確認してください。

わかりました、私がちょうどいたシナリオを想像してください：

あなたはmerge、または多分を試みcherry-pick、そしてあなたは

$ git cherry-pick 1023e24
error: could not apply 1023e24... [Commit Message]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

ここで、競合するファイルを表示し、変更を保存したくない場合。上記の私の場合、ファイルは私のIDEが自動追加した改行だけで競合していました。変更を元に戻して変更を受け入れるには、最も簡単な方法は次のとおりです。

git checkout --theirs path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

これの逆（着信バージョンを自分のバージョンで上書きする）は

git checkout --ours path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

驚いたことに、私はこの答えをネット上で簡単に見つけることができませんでした。

git pull -X theirs答えは醜いマージコミットを作成、または発行することができます

エラー：次のファイルに対するローカルの変更は、マージによって上書きされます：

たとえば常に常に起点のミラーであるはずのクライアント上で、リポジトリからのファイルに対するローカルの変更を単に無視したい場合は、これを実行します（master必要なブランチに置き換えます）。

git fetch && git reset --hard origin/master

どのように機能しますか？git fetchありませんgit pullが、マージしません。次にgit reset --hard、作業ツリーを最後のコミットに一致させます。リポジトリ内のファイルに対するローカルの変更はすべて破棄されますが、新しいローカルファイルはそのまま残ります。

gitマージ後、競合が発生し、自分または

git checkout --theirs .
git checkout --ours .

特定のブランチのバージョンとのすべての競合を解決するには：

git diff --name-only --diff-filter=U | xargs git checkout ${branchName}

したがって、すでにマージ状態にあり、競合するファイルのマスターバージョンを保持したい場合は、次のようにします。

git diff --name-only --diff-filter=U | xargs git checkout master

時々これが機能しないことに注意してください：

git checkout --ours path / to / file

または

git checkout-それらのパス/ to / file

HEADが私たちのものであり、MERGE_HEADが彼らのものであると仮定して、代わりにこれを行いました

git checkout HEAD -- path/to/file

または：

git checkout MERGE_HEAD -- path/to/file

これを実行すると、次のようになります。

git add .

詳細を知りたい場合は、こちらのtorekのすばらしい投稿を参照してください。git checkout --oursは、マージされていないファイルのリストからファイルを削除しません

VSコード（統合Git）IDEユーザー：

競合ファイル内のすべての着信変更を受け入れる場合は、次の手順を実行します。

1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming

同様に、Accept All Both、Accept All Currentなど、他のオプションについても実行できます。

私は、でnext-version変更されたdevelopファイル、両方のブランチの別の場所に追加されたファイルなどを大量に削除する長期実行ブランチを持っていました。

next-versionブランチの内容全体developを1つのなんとなくマージコミットに取り込みたいと思っていました。

私のために働いた上記のコマンドの組み合わせは：

git merge -X theirs next-version
# lots of files left that were modified on develop but deleted on next-version
git checkout next-version .
# files removed, now add the deletions to the commit
git add .
# still have files that were added on develop; in my case they are all in web/
git rm -r web

新しい答えではなく、多くの答えからのビットを組み合わせるだけで、部分的にはこれらすべての答えが必要になる可能性があることを安心させるためです。

すでに競合状態にあり、パスを1つずつチェックアウトしたくない場合。あなたは試すことができます

git merge --abort
git pull -X theirs

https://git-scm.com/book/en/v2/Git-Tools-Advanced-Mergingから

これは基本的に偽のマージを行います。両方のブランチを親として持つ新しいマージコミットを記録しますが、マージするブランチは調べません。マージの結果として、現在のブランチの正確なコードを記録するだけです。

$ git merge -s ours mundo

「ours」戦略によって作成されたマージ。

$ git diff HEAD HEAD~

私たちがいたブランチとマージの結果の間に違いがないことがわかります。

これは、基本的にGitをだまして、後でマージを行うときにブランチがすでにマージされていると考えるのに役立ちます。たとえば、リリースブランチから分岐して、ある時点でマスターブランチにマージする必要がある作業を行ったとします。それまでの間、マスターのバグ修正をリリースブランチにバックポートする必要があります。バグ修正ブランチをリリースブランチにマージし、同じブランチをマスターブランチにマージすることもできます（フィックスがすでに存在している場合でも）。後でリリースブランチを再度マージするときに、バグ修正による競合は発生しません。

新しいトピックブランチの変更をマスターに反映させたい場合に役立つ状況です。-Xtheirsはいくつかの状況で競合なしにマージしないことに気づきました...例

$ git merge -Xtheirs topicFoo 

CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.

この場合、私が見つけた解決策は

$ git checkout topicFoo

topicFooから、最初に-s ours戦略を使用してマスターにマージします。これにより、topicFooの状態である偽のコミットが作成されます。$ git merge -s私たちのマスター

作成されたマージコミットを確認する

$ git log

今マスターブランチをチェックアウト

$ git checkout master

トピックブランチをマージして戻しますが、今回は-Xtheirs再帰戦略を使用します。これにより、topicFooの状態のマスターブランチが表示されます。

$ git merge -X theirs topicFoo