当使用git merge将主题分支“B”合并为“A”时，我得到了一些冲突。我知道所有的冲突都可以用B的版本解决。
我知道git合并是我们的。但我想要的是类似git merge -s的东西。
为什么它不存在?如何在与现有git命令冲突合并后实现相同的结果?(git从B中检出所有未合并的文件)
仅仅丢弃分支A中的任何东西(合并提交点到树的B版本)的“解决方案”不是我想要的。
当前回答
重新审视这个老问题，因为我刚刚找到了一个兼而有之的解决方案 简短而且——因为它只使用瓷器指令——容易理解。 明确地说，我想回答的问题在标题中提出 问题(实现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 checkout -m old
git checkout -b new B
git merge -s ours old
类似的选项是——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命令执行实际删除操作将首先防止冲突的发生。
从现在起，我一直使用Paul Pladijs的答案。我发现，你可以做一个“正常的”合并，发生冲突，所以你这样做
git checkout --theirs <file>
通过使用来自其他分支的修订来解决冲突。如果对每个文件执行此操作，则会得到与预期相同的行为
git merge <branch> -s theirs
无论如何，这种努力比合并策略要多!(这是用git 1.8.0版本测试的)
这将合并现有的baseBranch中的newBranch
git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch
当合并主题分支“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
