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

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

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

等价于'git merge -s their branchB'(保持父顺序)

在合并之前:

! !确保你处于清洁状态!!

进行合并:

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

我们做了什么? 我们创建了一个新的提交，它的两个父节点是我们的和他们的，提交的连接是他们的分支b

合并后:

更准确地说应该是:

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

我解决了我的问题

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

重新审视这个老问题，因为我刚刚找到了一个兼而有之的解决方案 简短而且——因为它只使用瓷器指令——容易理解。 明确地说，我想回答的问题在标题中提出 问题(实现git merge -s their)，而不是问题体。在 换句话说，我想创建一个合并提交，它的树和 第二个父树:

# Start from the branch that is going to receive the merge.
git switch our_branch

# Create the merge commit, albeit with the wrong tree.
git merge -s ours their_branch

# Replace our working tree and our index with their tree.
git restore --source=their_branch --worktree --staged :/

# Put their tree in the merge commit.
git commit --amend

注意:git restore是git中引入的一个相当新的命令 2.23. Git帮助恢复警告

这个命令是实验性的。行为可能会改变。

我用多个版本的git (2.25.1, 2.30.2， 2.31.1, 2.34.1和2.35.1)，并按预期工作。

为什么它不存在?

虽然我在“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>在他们的分支作为提交被永久忽略”; 这很重要，因为如果您随后从分支的后面的状态合并，它们后面的更改将被引入，而不会引入被忽略的更改。

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

git checkout --theirs <file>

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

git merge <branch> -s theirs

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