【发布时间】：2016-06-01 14:53:20
【问题描述】：
所以我刚刚到达我作为承包商的现场....他们最近才开始使用源代码控制工具 (TFS 2015)。但它实际上只是用作备份的存储库。他们只使用文件夹，没有分支。
问题在于：我们有一个大型应用迁移项目，需要在不同程度上触及所有代码。同时，我们不能进行全局代码冻结，因为在实施应用程序迁移项目代码更改之前，可能需要在生产中实施紧急代码更改。我的想法是将任何给定应用程序的基本文件夹转换为分支并将其命名为 appName-main。然后，我将 -main 分支到 -appMigration，应用程序迁移项目将在其中工作。太好了，一切都很好......直到发生紧急变化，需要在我们的新数据中心完成 appMigration 项目之前在主干上实施。所以我继续分支 -main ，这次是 -EmergencyChange001 ，在完成一些工作后，它最终完成了。在这一点上，我想将 -EmergencyChange001 合并到 both -Main 和 -AppMigration 分支中。我能看到这样做的唯一方法是执行毫无根据的合并，但是有很多强烈的建议反对这样做。这是一种可以保证毫无根据的合并的情况，还是有更好的替代方案？提前致谢。
【问题讨论】：
-
为什么不从 EmergencyChange 合并到 Main，然后从 Main 合并到 AppMigration？
-
这是一个选项，但我不希望这样做，因为 Main 和 AppMigration 将在短期内大不相同，我们必须审查之前在 AppMigration 中所做的所有更改，以确保某些东西没有不要被覆盖。在 EmergencyChange 中制作的 mod 会少很多，所以合并后的审查会少很多。
-
所以 Main 更接近紧急变更？听起来它们非常相似。即紧急变化是主要的加上一些小的变化。在这种情况下，将紧急更改合并到 Main，然后将其合并到 AppMigration 与进行无根据的合并（内容方面）没有什么不同，这样您将遵循 TFS 建立的合并树。如果您进行毫无根据的合并，您将为自己制造一堆问题。这是某种程度的痛苦。与使用已建立的合并结构相比，毫无根据的合并对您的伤害更大。