在拉动期间解决Git合并冲突以支持其更改

Question

如何解决git合并冲突,支持拉动更改？

基本上我需要从工作树中删除所有冲突的更改,而不必经历所有冲突,git mergetool同时保持所有无冲突的更改.最好在拉动时这样做,而不是之后.

Answer 1

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

或者,简单地说,对于默认存储库:

git pull -X theirs

如果你已经处于冲突状态......

git checkout --theirs path/to/file

Answer 2

您可以使用递归的"他们的"策略选项:

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.

注:由于该男子页称,"我们的"合并的策略选项是从"我们"合并完全不同的策略.

Answer 3

如果你已经处于冲突状态,并且你想接受他们所有人:

git checkout --theirs .
git add .

如果你想做相反的事情:

git checkout --ours .
git add .

这是非常激烈的,所以在做之前确保你真的想要像这样擦除所有东西.

Answer 4

好吧,想象一下我刚才的情景:

你尝试了一个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

令人惊讶的是,我在网上很难找到这个答案.

Answer 5

该git pull -X theirs答案可能创建一个丑陋的合并提交,或发出

错误:合并将覆盖对以下文件的本地更改:

如果你想简单地忽略对repo文件的任何本地修改,例如在应该始终是原始镜像的客户端上,运行它(用master你想要的分支替换):

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

它是如何工作的？git fetch确实git pull没有合并.然后git reset --hard使您的工作树与最后一次提交匹配.对repo中文件的所有本地更改都将被丢弃,但新的本地文件将保持不变.

Answer 6

更新2024年！

如果您想接受所有当前更改并忽略任何传入更改，您可以这样做：

git merge [branch] --strategy-option ours

[branch]应替换为您要合并到当前分支的分支的名称。

相反，如果您知道要覆盖任何当前更改并接受传入更改的所有冲突，则可以使用theirs以下策略：

git merge [branch] --strategy-option theirs

Answer 7

要解决与特定分支中的版本的所有冲突:

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

因此,如果您已处于合并状态,并且您希望保留冲突文件的主版本:

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

Answer 8

git checkout --ours/theirs并不能完全解决冲突。它从任一ours/theirs.

假设我们有一个文件，foo其中有两次提交/分支/树/其他内容的更改。如果他们引入了冲突以及修改，并且我们希望使用ours-- 解决冲突，那么使用checkout --ours foo将丢弃引入冲突的更改以及修改。

使用 SED

使用他们的解决方案：

sed -i -e '/^<<<<<<</,/^=======/d' -e '/^>>>>>>>/d' foo

• -i就地修改文件，
• /^<<<<<<</,/^=======/d删除介于（包括）<<<<<<<和=======（我们的）之间的所有内容
• /^>>>>>>>/d删除剩余的冲突标记
• -e为 SED 指定多个模式
• foo文件

使用我们的解决方案：

sed -i -e '/^<<<<<<</d' -e '/^=======/,/^>>>>>>>/d' foo

我制作了一个你可以调用的脚本git resolve -o/-t/-b。

创建自定义合并工具

您可以创建自定义合并工具。在上述脚本的基础上，sed您可以将类似的内容放入您的git-config：

[mergetool "ours"]
    cmd = "sed -i -e '/^<<<<<<</d' -e '/^=======/,/^>>>>>>>/d' -- $MERGED"

并称之为git mergetool --tool=ours

合并样式

请注意，还有其他非标准合并样式，如diff3@Stavroszdiff3在评论中指出的那样。冲突标记的数量在 git 中也没有硬编码为 7。我相信这主要只是默认设置，我记得它是可以配置的。

sed可以调整基本脚本以适用于所有配置。

Answer 9

请注意,有时这不起作用:

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 .

如果你想了解更多,请在这里查看torek的精彩帖子: git checkout --ours不会从未合并文件列表中删除文件

Answer 10

如果您已经处于冲突状态，并且不想一一检出路径。你可以试试

git merge --abort
git pull -X theirs

Answer 11

VS Code（集成Git）IDE用户：

如果要接受冲突文件中的所有传入更改，请执行以下步骤。

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

同样，您可以对其他选项执行操作，例如“ 全部接受”，“全部接受当前”等，

Answer 12

git merge之后，如果您遇到冲突并且想要自己或他们的

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

Answer 13

\n

来自https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging

\n\n

这基本上会进行一次假合并。它将记录一个新的合并提交，并将两个分支作为父分支，但它甚至不会查看您要合并的分支。它只会记录确切的合并结果您当前分支中的代码。

\n\n

$ git merge -s ours mundo\n

\n\n

由“我们的”策略进行的合并。

\n\n

$ git diff HEAD HEAD~\n

\n\n

你可以看到我们所在的分支和合并的结果没有区别。

\n\n

这通常很有用，可以让 Git 认为在稍后进行合并时已经合并了一个分支。例如，假设您从一个发布分支分支出来，并对其进行了一些工作，您希望在某个时候合并回主分支。与此同时，master 上的一些错误修复需要向后移植到您的发布分支中。您可以将 bugfix 分支合并到release分支中，也可以将 -s 我们的同一个分支合并到您的 master 分支中（即使修复已经存在），因此当您稍后再次合并release分支时，会有错误修正没有冲突。

\n

\n\n

如果我希望 master 反映新主题分支的更改，我发现这种情况很有用。我注意到 -Xtheirs 在某些情况下不会在没有冲突的情况下合并...\ne.g。

\n\n

$ git merge -Xtheirs topicFoo \n\nCONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.\n

\n\n

在这种情况下，我找到的解决方案是

\n\n

$ git checkout topicFoo\n

\n\n

从 topicFoo 开始，首先使用 -s ours 策略合并到 master 中，这将创建一个假提交，它只是 topicFoo 的状态。\n$ git merge -s ours master

\n\n

检查创建的合并提交

\n\n

$ git log\n

\n\n

现在检查主分支

\n\n

$ git checkout master\n

\n\n

将主题分支合并回来，但这次使用 -Xtheirs 递归策略，现在将为您提供一个状态为 topicFoo 的主分支。

\n\n

$ git merge -X theirs topicFoo\n

\n