是否有“他们的”版本的“ git merge -s ours”？

使用将主题分支“ B”合并到“ A”时git merge，出现了一些冲突。我知道可以使用“ B”中的版本解决所有冲突。

我知道git merge -s ours。但是我想要的是类似的东西git merge -s theirs。

为什么不存在？与现有git命令发生冲突合并后，如何获得相同的结果？（git checkout来自B的每个未合并文件）

更新：只是从分支A中丢弃任何东西（合并提交点到树的B版本）的“解决方案”不是我想要的。

将-X选项添加到theirs。例如：

git checkout branchA
git merge -X theirs branchB

一切都会以所需的方式合并。

我所见的唯一引起问题的原因是文件是否从branchB中删除。如果除git以外的其他操作删除，它们将显示为冲突。

修复很容易。只需git rm使用已删除的任何文件的名称运行：

git rm {DELETED-FILE-NAME}

之后，-X theirs应该可以按预期工作。

当然，使用该git rm命令进行实际删除将首先避免发生冲突。

注意：还存在一个较长的表格选项。

要使用它，请替换：

-X theirs

与：

--strategy-option=theirs

将BranchB合并到我们已签出的BranchA中的可行且经过测试的解决方案：

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

要使其自动化，您可以使用branchA和branchB作为参数将其包装到脚本中。

就像您期望的那样，此解决方案保留了合并提交的第一和第二父级git merge -s theirs branchB。

较早版本的git允许您使用“其”合并策略：

git pull --strategy=theirs remote_branch

但这已被删除，正如Junio Hamano（Git维护者）在此消息中所解释的。如链接中所述，您可以执行以下操作：

git fetch origin
git reset --hard origin

但是请注意，这与实际合并不同。您的解决方案可能是您真正想要的选择。

目前尚不清楚您期望的结果是什么，因此在答案和评论中对“正确”的实现方式有些困惑。我尝试给出一个概述，并查看以下三个选项：

尝试合并并使用B解决冲突

这不是 “他们的版本git merge -s ours”，而是“他们的版本git merge -X ours”（是的缩写git merge -s recursive -X ours）：

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

这就是艾伦·史密斯（Alan W. Smith）的答案。

仅使用B中的内容

这会为两个分支创建一个合并提交，但会丢弃的所有更改，branchA而只会保留的内容branchB。

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

请注意，合并现在提交的第一个父对象是from branchB，只有第二个提交是from branchA。例如，Gandalf458的答案就是这样做的。

仅使用B的内容并保持正确的父顺序

这是真正的“他们的版本git merge -s ours”。它的内容与之前的选项相同（即仅来自from branchB），但是父级的顺序是正确的，即，第一个父级来自，branchA第二个父级来自branchB。

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

这就是Paul Pladijs的回答（不需要临时分支）。

从现在开始，我一直使用Paul Pladijs的答案。我发现，您可以进行“常规”合并，发生冲突，因此您可以

git checkout --theirs <file>

通过使用另一个分支的修订来解决冲突。如果对每个文件执行此操作，则将具有与预期相同的行为

git merge <branch> -s theirs

无论如何，这比合并策略要付出更多的努力！（这已在git版本1.8.0中进行了测试）

我用解决了我的问题

git checkout -m old
git checkout -b new B
git merge -s ours old

当使用git merge在“ A”中合并主题分支“ B”时，出现一些冲突。我知道所有冲突都可以使用“ B”中的版本解决。

我知道git merge -s我们的。但是我想要的是git merge> -s他们的东西。

我假设您创建了master分支，现在想合并回master，覆盖master中的所有旧内容。这正是我遇到这篇文章时想要做的。

确切地执行您要执行的操作，除了首先将一个分支合并到另一个分支中。我就是这样做的，效果很好。

git checkout Branch
git merge master -s ours

然后，结帐master并合并其中的分支（现在可以顺利进行）：

git checkout master
git merge Branch

如果您在分支机构A上，请执行以下操作：

git merge -s recursive -X theirs B

在git版本1.7.8上测试

要真正做到正确的合并这需要只从分支要合并，你可以做输入

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

据我所知，在任何情况下都不会发生冲突，您不必进行其他分支，并且它的行为就像普通的合并提交一样。

但是，这在子模块中效果不佳。

为什么不存在？

虽然我在“ git命令使一个分支像另一个分支 ”中提到了如何模拟git merge -s theirs，但请注意，Git 2.15（2017年第四季度）现在更加清晰：

-X<option>误写了“ ”用于合并的文档以表明-s theirs存在“ ”，事实并非如此。

参见Junio C Hamano（）提交的commit c25d98b（25 Sep 2017 ）。^{（通过合并JUNIOÇ滨野- -在提交4da3e23，2017年9月28日）}gitster
gitster

合并策略：避免暗示“ -s theirs”存在

-Xours合并选项的描述带有括号，告诉读者它与完全不同-s ours，这是正确的，但-Xtheirs随后的描述却粗心地说“这与ours” 相反，给人以错误的印象，认为读者也需要请注意，它与完全不同-s theirs，实际上甚至不存在。

-Xtheirs是应用于递归策略的策略选项。这意味着递归策略仍将合并所有可能的内容，并且仅theirs在发生冲突时才退回到逻辑上。

有关theirs合并策略是否相关的争论最近在2017年9月的这个话题中引起了人们的注意。
它承认较旧的（2008）线程

简而言之，前面的讨论可以总结为“我们不希望' -s theirs'，因为它会鼓励错误的工作流程”。

它提到了别名：

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

雅罗斯拉夫·哈尔琴科（Yaroslav Halchenko）尝试再次倡导该战略，但Junio C. Hamano补充说：

我们和他们之所以不对称的原因是因为你是你而不是他们-我们历史及其历史的控制和所有权不是对称的。

一旦确定他们的历史是主线，您就希望将您的开发线视为分支，并在该方向上进行合并，即，产生的合并的第一个父项是对他们的历史的提交，第二个父母是您历史上的最后一个坏人。因此，您最终将使用“ checkout their-history && merge -s ours your-history”来保持初婚年龄。

在这一点上，使用“ -s ours”不再是缺少“ -s theirs” 的解决方法。
它是所需语义的适当部分，即，从尚存的规范历史路线的角度来看，您想要保留它所做的事情，而使其他历史路线所做的事情无效。

Junio补充说，正如Mike Beaton所说：

git merge -s ours <their-ref>有效地说：“标记提交<their-ref>在其分支上构成为永久忽略的提交”；
这很重要，因为如果您随后从其分支的较后状态进行合并，则将引入其较晚的更改，而不会引入任何被忽略的更改。

请参见Junio Hamano广为引用的答案：如果您要丢弃已提交的内容，请丢弃已提交的内容，或者至少将其排除在主要历史记录之外。为什么将来要打扰每个人都从没有提供内容的提交中读取提交消息？

但是有时会有管理要求，或者可能还有其他原因。对于那些您确实必须记录毫无贡献的提交的情况，您需要：

（编辑：哇，我以前设法弄错了吗。这个有效。）

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

这使用了一个git plumbing命令read-tree，但是使整个工作流程缩短了。

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

这会将您的newBranch合并到现有的baseBranch中

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

我认为您真正想要的是：

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

这看起来很笨拙，但应该可以。我真正不喜欢此解决方案的唯一想法是git历史记录会令人困惑……但是至少历史记录将被完全保留，并且您不需要为已删除的文件做一些特殊的事情。

等同于（保持父顺序）'git merge -s他们的branchB'

合并之前：

!!! 确保您处于清洁状态！

进行合并：

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

我们做了什么 ？我们创建了一个新的提交，其中有我们的两个父母和他们的父母，该提交的内容是branchB-他们的父母

合并后：

更确切地说：

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

保罗·普拉迪斯（Paul Pladijs）给出了这个答案。为了方便起见，我只是接受了他的命令并制作了一个git别名。

编辑您的.gitconfig并添加以下内容：

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

然后，您可以通过运行以下命令“ git merge -s thems A”：

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

我最近刚刚需要对两个共享相同历史记录的独立存储库执行此操作。我开始于：

• Org/repository1 master
• Org/repository2 master

我希望将所有更改repository2 master都应用于repository1 master，接受repository2所做的所有更改。用git的术语来说，这应该是一种称为-s theirsBUT 的策略，但它并不存在。请小心，因为-X theirs它的名称就像您想要的一样，但是名称并不相同（甚至在手册页中也是如此）。

我解决这个问题的方法是去建立repository2一个新的分支repo1-merge。在那个分支中，我运行了git pull git@gitlab.com:Org/repository1 -s ours，并且合并得很好，没有任何问题。然后，我将其推到遥控器上。

然后我回到repository1并建立一个新分支repo2-merge。在该分支中，我git pull git@gitlab.com:Org/repository2 repo1-merge将运行所有问题。

最后，您可能需要发出合并请求repository1以使其成为新的主服务器，或者只是将其保留为分支。

一种简单直观的方法（在我看来）是两步

git checkout branchB .
git commit -m "Picked up the content from branchB"

其次是

git merge -s ours branchB

（将两个分支标记为合并）

唯一的缺点是它不会从当前分支中删除在branchB中已删除的文件。之后，两个分支之间的简单差异将显示是否存在任何此类文件。

此方法还可以从修订日志中清楚地知道随后进行的操作和预期的操作。