从现在起，我一直使用Paul Pladijs的答案。我发现，你可以做一个“正常的”合并，发生冲突，所以你这样做

git checkout --theirs <file>

通过使用来自其他分支的修订来解决冲突。如果对每个文件执行此操作，则会得到与预期相同的行为

git merge <branch> -s theirs

无论如何，这种努力比合并策略要多!(这是用git 1.8.0版本测试的)

这并不一定能回答最初发帖者的问题，但我在这里遇到的情况是，我已经尝试了合并，但最终发生了冲突。通常我在IDE中管理冲突，但当我无法访问时，可以使用以下REGEX来查找并替换“their”内容的差异:

Replce <<<<<<< HEAD\n[^•>]+\n==========\n（[^•>]+）>>>>>>> .+\n with \1

(以防其他人因为和我一样的原因登陆这个页面)。

旧版本的git允许你使用“their”合并策略:

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递归-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

请注意，合并提交的第一个父节点是来自branchB的，只有第二个是从branchA提交的。这就是例如Gandalf458的答案所做的。

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

这是真正的“他们版本的git合并-我们的”。它的内容与之前的选项相同(即只有来自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的答案所做的(不需要一个临时分支)。

特殊情况

如果branchB的提交是branchA的祖先，git merge将不起作用(它只会退出，并显示“Already up to date.”这样的消息)。

在这种或其他类似/高级的情况下，可以使用低级命令git提交树。

一个简单而直观的(在我看来)两步方法是

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

紧随其后的是

git merge -s ours branchB

(将两个分支标记为合并)

唯一的缺点是它不能从当前分支中删除branchB中已删除的文件。然后，两个分支之间的简单区别将显示是否存在这样的文件。

这种方法还可以从之后的修订日志中清楚地看出所做的工作以及意图。

为什么它不存在?

虽然我在“git命令使一个分支像另一个分支一样”中提到了如何模拟git合并-s，但请注意，git 2.15(2017年Q4)现在更清晰了:

用于合并的'-X<option>'的文档具有误导性 写的是“-s their”的存在，但事实并非如此。

参见Junio C Hamano (gitster)的commit c25d98b(2017年9月25日)。 (由Junio C Hamano—gitster—在commit 4da3e23,2017年9月28日合并)

合并策略:避免暗示“-s their”的存在 -Xours合并选项的说明有一个插入说明 这告诉读者，它与我们的-s非常不同， 这是正确的，但是后面的- xtheir的描述 不小心说“这是我们的相反”，给了一个错误 这种印象也需要提醒读者，它是非常的 不同于他们的-s，而后者在现实中根本不存在。

xtheir是一个应用于递归策略的策略选项。这意味着递归策略仍然会合并任何它可以合并的东西，并且只会在发生冲突时退回到“他们的”逻辑。

关于他们合并战略的相关性的争论最近在2017年9月的帖子中被重新提起。 它承认旧线程(2008年)

简而言之，前面的讨论可以总结为“我们不想要‘-s their’，因为它鼓励错误的工作流程”。

它提到了别名:

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

Yaroslav Halchenko试图再次倡导这一策略，但是Junio C. Hamano补充道:

The reason why ours and theirs are not symmetric is because you are you and not them---the control and ownership of our history and their history is not symmetric. Once you decide that their history is the mainline, you'd rather want to treat your line of development as a side branch and make a merge in that direction, i.e. the first parent of the resulting merge is a commit on their history and the second parent is the last bad one of your history. So you would end up using "checkout their-history && merge -s ours your-history" to keep the first-parenthood sensible. And at that point, use of "-s ours" is no longer a workaround for lack of "-s theirs". It is a proper part of the desired semantics, i.e. from the point of view of the surviving canonical history line, you want to preserve what it did, nullifying what the other line of history did.

正如Mike Beaton所评论的那样，Junio补充道:

Git merge -s ours <their-ref>有效地说“标记提交构成<their-ref>在他们的分支作为提交被永久忽略”; 这很重要，因为如果您随后从分支的后面的状态合并，它们后面的更改将被引入，而不会引入被忽略的更改。