1

我正在尝试将一个分支合并到 master 中，但想确保来自另一个分支的所有更改都生效，无论如何，但不知道如何去做？主要问题是我们最终会在 50 个文件中发生合并冲突，我们不关心 master 的先前状态。

故事：主分支已在 2018 年发布，而 2019 年发布的工作已在另一个分支中完成。由于运行时环境依赖性变化的影响，2019 年的变化很复杂，需要丢弃大部分 2018 年的变化。我们现在想要从 2019 年开始进行所有更改，并使其成为 master 的新状态。

到目前为止我尝试过的（作为单独的尝试）：

git merge 2019-release
git merge -X theirs 2019-release
git merge -s recursive -X theirs 2019-release

最后一个似乎更好，但遇到了重命名和删除文件的问题，其中有很多，因为我们包含的框架已被重写。

想知道是否采用焦土类型的方法来掌握（清除所有文件并提交），然后进行合并将是另一种方法？

我确实尝试过查看 Stack Overflow，但没有找到似乎可以正确解决该问题的答案。

任何建议，将不胜感激？

4

1 回答 1

3

您正在寻找的内容接近您尝试的最后一个。

git merge -X ours（甚至）使用sidegit merge -s recursive -X ours自动解决冲突。ours（文档）

git merge -s ours从接收分支中获取所有内容，无论是否冲突，从而完全丢弃theirs侧面的更改。

奇怪的是，页面中对应的段落有相同的锚链接，一定是一个小错误，但一定要检查两个条目并比较。我无法链接最相关的一个，因为它也指向另一个，但它说：

这解决了任意数量的头，但合并的结果树始终是当前分支头的树，有效地忽略了所有其他分支的所有更改。它旨在用于取代分支的旧开发历史。请注意，这与递归合并策略的 -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侧面，仍然将操作标记为合并，尽管有些人可能会争辩说这在技术上是一个覆盖。

于 2019-04-07T21:45:48.943 回答