如何解决git合并冲突，转而采取拉动更改？
基本上我需要从工作树中删除所有冲突的更改，而不必经历与git mergetool的所有冲突，同时保持所有无冲突的更改。最好在拉动时这样做，而不是之后。
答案 0 :(得分：880)
git pull -s recursive -X theirs <remoterepo or other repo>
或者，简单地说，对于默认存储库：
git pull -X theirs
If you're already in conflicted state...
git checkout --theirs path/to/file
答案 1 :(得分：808)
您可以使用递归的“他们的”策略选项：
git merge --strategy-option theirs
来自man：
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.
注意：正如手册页所述，“我们的”合并策略选项与“我们的”合并策略非常不同。
答案 2 :(得分：369)
如果您已经处于冲突状态，并且您只想接受他们的全部：
git checkout --theirs .
git add .
如果你想做相反的事情：
git checkout --ours .
git add .
这是非常激烈的，所以在做之前一定要确保你真的要把这些东西擦掉。
答案 3 :(得分：214)
好的，想象一下我刚才的情景：
您尝试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
令人惊讶的是，我无法在网上轻易找到这个答案。
答案 4 :(得分：25)
git pull -X theirs个答案可能会造成丑陋的合并提交，或者发出
错误：合并后将覆盖对以下文件的本地更改：
如果您想简单地忽略对repo中文件的任何本地修改，例如在应该始终是原始镜像的客户端上，请运行此命令（将master替换为您想要的分支）：< / p>
git fetch && git reset --hard origin/master
它是如何工作的？ git fetch does git pull but without merge。然后git reset --hard使您的工作树与最后一次提交匹配。对repo中文件的所有本地更改都将为discarded，但新的本地文件将保持不变。
答案 5 :(得分：18)
解决与特定分支中的版本的所有冲突：
git diff --name-only --diff-filter=U | xargs git checkout ${branchName}
因此，如果您已经处于合并状态，并且希望保留冲突文件的主版本：
git diff --name-only --diff-filter=U | xargs git checkout master
答案 6 :(得分：14)
请注意，有时这会无效：
git checkout --ours path / to / file
或
git checkout - 他们的路径/到/文件
我这样做了，假设 HEAD是我们的而 MERGE_HEAD是他们的
git checkout HEAD -- path/to/file
或：
git checkout MERGE_HEAD -- path/to/file
在我们这样做之后，我们很好：
git add .
如果您想了解更多信息，请参阅此处的精彩帖子： git checkout --ours does not remove files from unmerged files list
答案 7 :(得分：8)
git合并后，如果您遇到冲突并且希望自己或他们
git checkout --theirs .
git checkout --ours.
答案 8 :(得分：6)
如果您已经处于冲突状态，并且不想一一签出路径。您可以尝试
git merge --abort
git pull -X theirs
答案 9 :(得分：4)
VS Code（集成Git）IDE用户：
如果您要接受冲突文件中的所有 所有传入更改 ，请执行以下步骤。
1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming
类似地，您可以使用其他选项，例如全部接受，全部接受当前等
答案 10 :(得分：1)
我有一个长期运行的next-version分支，其中对develop上已更改的文件，两个分支上不同位置添加的文件等进行了大量删除。
我想将next-version分支的全部内容带入develop，所有这些都需要一次合并合并提交。
以上对我有用的命令的组合是：
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
这不是一个新的答案，只是将许多答案中的一部分相结合，部分是为了确保您可能需要所有这些答案。
答案 11 :(得分：1)
git checkout --ours/theirs 不专门解决冲突。它从 ours/theirs 中检出（获取整个文件）。
假设我们有一个文件 foo，其中有两个提交/分支/树/任何内容的更改。如果他们引入了冲突以及修改，并且我们想使用 ours 解决冲突 - 那么使用 checkout --ours foo 将丢弃引入冲突的更改，以及修改。< /p>
sed -i -e '/<<<<<<</,/=======/d' -e '/>>>>>>>/d' foo
-i 修改文件，/<<<<<<</,/=======/d 删除 <<<<<<< 和 =======（我们的）之间的所有内容/>>>>>>>/d 删除剩余的冲突标记-e 为 SED 指定多个模式foo 文件sed -i -e '/<<<<<<</d' -e '/=======/,/>>>>>>>/d' foo
答案 12 :(得分：-1)
来自https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging
这基本上会做假合并。它将记录一个新的合并提交 两个分支作为父母，但它甚至不会看分支 你正在合并。它只会记录合并的结果 当前分支中的确切代码。
$ git merge -s ours mundo“我们的”战略合并。
$ git diff HEAD HEAD~你可以看到我们所在的分支没有区别 和合并的结果。
这基本上可以帮助Git认为a 稍后进行合并时，分支已合并。例如，说 你分支了一个发布分支并做了一些工作 你想在某个时候合并回你的主分支。在 与此同时，master上的一些bugfix需要被反向移植到你的 发布分支。您可以将bugfix分支合并到发行版中 分支并将我们的同一分支合并到您的主分支中 （即使修复已经存在）所以当你以后合并时 再次发布分支，错误修复没有冲突。
如果我希望master能够反映新主题分支的更改，我发现这种情况很有用。我注意到-Xtheirs在某些情况下没有冲突就没合并...... e.g。
$ 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
，首先使用-s我们的策略在master中合并，这将创建只是topicFoo状态的伪提交。 $ git merge -s our master
检查创建的合并提交
$ git log
现在检查主分支
$ git checkout master
合并主题分支，但这次使用-Xtheirs递归策略，现在将为您提供一个主分支，其状态为topicFoo。
$ git merge -X theirs topicFoo