我们正在对我们的网站进行重大修订。修改后的站点上的所有工作都在一个 git 分支(称为 2.0)中完成，该分支是前一段时间从 master 分支出来的。在此过程中，已经进行了一些小的和重要的更改以掌握，我们希望将这些更改 merge 到 2.0 中。
然而，将其作为一个大型 merge 来执行似乎很笨拙——虽然一些更改会很好地 merge ，但其中一些涉及 2.0 上不再存在的代码，并且基本上需要在 2.0 上重新实现新功能。只要 merge 后还有一堆 Unresolved 冲突，修复这些功能可能会非常困难。我们考虑过使用 cherry-pick 只从 master 带来那些可以很好地 merge 的更改，同时手动重新实现主要更改，但我认为如果我们想将 2.0 中的所有更改 merge 回大师。
理想情况下，我可以从 master 到 2.0 进行分段 merge ——将一组次要提交 merge 到一个特定的提交，然后 merge 一个主要的提交并手动重新实现一个特定的新功能，然后是另一个系列，如此最后，master 完全 merge 到 2.0 中的一种方式。对于这种情况，这是一个好方法吗？如果是这样，我如何中途 merge 到 master，而不是一直 merge 到最近的 master 提交？或者我应该采取其他更好的方法吗？
最佳答案
您当然可以通过引用提交哈希而不是分支名称来零散地 merge 到一个分支中。所以说你想 merge 到 master 行上的特定提交 - 假设它是 abcd1234 - 你可以简单地进入你的 2.0 分支并运行:
git merge abcd1234
使用这种方法，您可以随心所欲地一次提交任意数量的提交。如果您遇到冲突，您可以只解决那个冲突，而不必一次处理所有冲突。
如果您在 master 分支上有更改，您知道这些更改仅与您的分支上不存在的代码相关，因此完全过时，您可以运行:
git merge --strategy=ours bcde2345
这将为 master 上的更改创建一个 merge 提交，但不会更改树的内容与它们在 2.0 上的内容，因此提交将是标记为已 merge ，实际上没有做任何事情。
关于Git:主要版本更改的分段 merge 方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8659544/