这个答案是由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 their A”通过运行:

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

将分支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一样。

类似的选项是——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 merge——strategy=我们的ref-to-be-merge

Git diff——binary ref-to-be-merged | Git apply——reverse——index

Git提交—修改

在我所知道的任何场景中都不会有冲突，您不必创建额外的分支，它就像正常的合并提交一样。

然而，这在子模块中并不适用。

我最近需要为两个共享共同历史的独立存储库执行此操作。我从:

Org/repository1主 Org/repository2主

我希望将repository2 master的所有更改应用到repository1 master，接受repository2所做的所有更改。在git的术语中，这应该是一个称为-s their的策略，但它不存在。要小心，因为-X their的名字就像你想要的那样，但它不是一样的(它甚至在手册页中这样说)。

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

然后回到repository1并创建一个新的分支rep2 -merge。在该分支中，我运行git拉git@gitlab.com:Org/repository2 repo1-merge，它将与问题一起完成。

最后，您可能需要在repository1中发出合并请求，使其成为新的主节点，或者只是将其作为一个分支。

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

git checkout --theirs <file>

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

git merge <branch> -s theirs

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