重新审视这个老问题，因为我刚刚找到了一个兼而有之的解决方案 简短而且——因为它只使用瓷器指令——容易理解。 明确地说，我想回答的问题在标题中提出 问题(实现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)，并按预期工作。

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

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中发出合并请求，使其成为新的主节点，或者只是将其作为一个分支。

将分支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命令执行实际删除操作将首先防止冲突的发生。

当合并主题分支“B”在“A”使用git合并，我得到一些冲突。我知道所有的冲突都可以用“B”中的版本来解决。 我知道git合并是我们的。我想要的是git merge >-s their。

我假设你从master创建了一个分支，现在想合并回master，覆盖master中的任何旧东西。当我看到这篇文章时，这正是我想做的。

做你想做的，除了先把一个分支合并到另一个分支。我就这么做了，效果很好。

git checkout Branch
git merge master -s ours

然后，签出master并合并你的分支(现在会很顺利):

git checkout master
git merge Branch

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

git checkout --theirs <file>

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

git merge <branch> -s theirs

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