将分支b合并到签出的分支cha的一个可能的和经过测试的解决方案:

# 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 their branchB一样。

等价于'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命令使一个分支像另一个分支一样”中提到了如何模拟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>在他们的分支作为提交被永久忽略”; 这很重要，因为如果您随后从分支的后面的状态合并，它们后面的更改将被引入，而不会引入被忽略的更改。

类似的选项是——strategy-option(简称-X)选项，它接受他们的选项。例如:

git checkout branchA
git merge -X theirs branchB

但是，它更等于-X而不是-s。关键的区别在于-X执行常规的递归合并，使用所选的一方解决任何冲突，而-s则将合并更改为完全忽略另一方。

在某些情况下，使用-X their而不是假设的-s their的主要问题是删除文件。在这种情况下，只需运行git rm，并输入已删除文件的名称:

git rm {DELETED-FILE-NAME}

在那之后，他们的-X可能会像预期的那样工作。

当然，使用git rm命令执行实际删除操作将首先防止冲突的发生。

这一个使用了git管道命令读树，但是使得整个工作流程更短。

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>

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

git pull --strategy=theirs remote_branch

但是这已经被删除了，正如Junio Hamano (Git维护者)在这条消息中解释的那样。正如链接中提到的，相反，你会这样做:

git fetch origin
git reset --hard origin

但是要注意，这与实际的合并不同。你的解决方案可能就是你真正在寻找的选项。