我正在尝试将一个分支合并到master，但是想要确保对另一个分支的所有更改都能生效，无论如何，但不确定如何进行？主要问题是，我们最终会在50个文件中发生合并冲突，而不必关心先前的master状态。
故事：master分支已在2018年发布，而2019年发布的工作已在另一个分支中完成。由于运行时环境依赖项更改的影响，2019年的更改非常复杂，需要丢弃2018年更改的很大一部分。现在，我们希望采用2019年以来的所有更改，并使它们成为新的掌握状态。
到目前为止，我已经尝试过（单独尝试）：
git merge 2019-release
git merge -X theirs 2019-release
git merge -s recursive -X theirs 2019-release
最后一个似乎更好，但是由于我们包含的框架已被重写，因此涉及重命名和删除文件的问题很多。
想知道是否采用焦土类型的方法来掌握（清除所有文件并提交），然后进行合并是另一种方法吗？
我确实尝试过Stack Overflow，但是没有找到似乎可以正确解决该问题的答案。
有什么建议会受到赞赏吗？
答案 0 :(得分：1)
您正在寻找的是接近您尝试过的最后一个。
git merge -X ours（甚至是git merge -s recursive -X ours）会使用ours端自动解决冲突。 （doc）
git merge -s ours从接收分支中收取一切，有无冲突。
奇怪的是，页面中的相应段落具有相同的锚链接，必须是一个小错误，但请务必检查两个条目并进行比较。我无法链接最相关的一个，因为它也指向另一个，但是它说：
这可以解析任意数量的head，但是合并的结果树始终是当前分支head的树，有效地忽略了所有其他分支的所有更改。它旨在取代侧支的旧开发历史。请注意，这与递归合并策略的-Xours选项不同。
等等
# we have to work from the 2019-release side since there is no theirs version for -s
git checkout 2019-release
git merge -s ours master
# at this point we have to reflect the operation on master
# (the second merge is just a fast-forward)
git checkout master
git merge 2019-release
这将占用2019-release方面的所有信息，并且仍将操作标记为合并，尽管有些人可能会认为这是覆盖。