除了在TFS 2015中执行无基础合并，还有其他选择吗？

所以我刚刚到达现场，我是一名承包商……他们最近才开始使用源代码控制工具（TFS 2015）。但它实际上只是用作一个可备份的存储库。他们只使用文件夹，没有分支

---

问题是：我们有一个大型的应用程序迁移项目，需要对所有代码进行不同程度的修改。同时，我们不能进行全局代码冻结，因为可能需要在应用程序迁移项目代码更改实施之前在生产中实施紧急代码更改。我的想法是将任何给定应用程序的基本文件夹转换为一个分支，并将其命名为appName main。然后，我将把-main分支到-appMigration，在那里进行应用程序迁移项目。很好，一切都很好…直到紧急变更出现，需要在新数据中心完成appMigration项目之前在主平台上实施。所以我继续，再次分支主，这次是紧急变更001，在一些工作完成后，它最终完成。此时，我想将-EmergencyChange001合并到-Main和-AppMigration分支中。我能看到的唯一方法是执行一个无根据的合并，但是有很多强烈的建议反对这样做。这是一种值得进行毫无根据的合并的方案，还是有更好的替代方案？提前谢谢

无基础合并可以在您的场景中使用，但我建议您在工作中尽量避免使用它，因为它可能会在将来带来更多问题。一些信息供您参考：

,

正如詹姆斯在评论中提到的，在你的情况下

-紧急变更001=-主要+紧急变更

---

一旦将-EmergencyChange001合并到-Main，最新的-Main将与-EmergencyChange001相同。所以merge-EmergencyChange001到-Main，然后merge-Main到-appMigration比baseless merge更好。

为什么不从EmergencyChange到Main合并，然后从Main到appMigration合并呢？这是一个选项，但我不喜欢，因为Main和appMigration在短时间内会有很大的不同，我们必须检查之前在AppMigration中所做的所有更改，以确保某些内容不会被覆盖。紧急变更中的MOD会少很多，所以合并后的审查会少很多。那么Main更接近紧急变更？听起来他们非常相似。i、 紧急变化是主要的，再加上一些小变化。在这种情况下，将紧急更改合并到Main，然后将其合并到AppMigration与执行无基础合并（内容方面）没有区别，这样您将遵循TFS建立的合并树。如果你做一个毫无根据的合并，你将为自己制造一堆问题。这是一定程度的疼痛。与使用已建立的合并结构相比，无基础的合并对您的伤害更大。