自定义版本的 TFS 分支，从合并回来排除那些自定义？

Question

我最近继承了一个没有版本控制的 ASP.Net Web Forms 项目，我正试图将它移到 TFS 中。在某些时候，该项目被拆分为一个客户端创建一个自定义版本，其中登录使用 ADFS 而不是我们的数据库驱动表单。拆分后，在主版本中添加了一些功能来管理用户；自定义版本中不需要这些。如果对一个版本的任何更改影响到非定制部分，则手动将其应用于另一个版本（尽管可以预见，这有时会被遗忘）。

每个版本在开发和生产服务器上都有一个文件夹，所以文件夹结构是这样的：

/Production/General
/Production/Custom
/Dev/General
/Dev/Custom

假设很难通过功能切换将两个版本完全合并，那么管理此问题的最佳方法是什么？

我在想我可以使用 diff 来提取生产版本的共同点，并将其作为我的 MAIN 分支。然后我可以让两个生产版本从 MAIN 分支，并将它们的当前状态作为第一次签入，然后对 dev 文件夹执行类似的操作，如下所示：

- MAIN
  | |- General
  |    |- GeneralDev
  |
  |- Custom
     |- CustomDev

但是，我不确定如何管理合并。有没有办法防止某些文件只在某些分支之间合并？如果我在 CustomDev 中进行更改，我希望将其正常合并到 General，然后我希望能够将该更改转移到 General 和 GeneralDev，而无需拉取 Custom 具有的所有其他自定义...

有没有办法很好地做到这一点（每次合并时都不必排除文件），还是我只需将它们视为两个单独的项目并手动同步更改？

Answer 1

使用分支应该简化合并操作而不是手动执行，因为分支可以帮助您了解更改的历史记录。您可能必须定义一个仔细的合并程序，以确保始终正确完成合并 - 这可能涉及限制允许合并的人员，因为太多的厨师往往会破坏肉汤。

但是，请考虑在这种情况下合并的成本和风险不断增加 - 这是一笔巨大的技术债务，因为任何需要合并的更改都会花费您大约 4 倍的成本来实施。仅仅测试两个分支都不受小变化的影响是很困难的，因为您必须先签入并合并才能确定是否可以 - 最好能够在您的 PC 上构建这两个变体并在您检查任何内容之前对其进行测试在。

至少您应该尽量减少所需的合并，因此请查看可以重构代码库的地方（可能随着时间的推移逐渐）以减少合并的需要。查看您获得最多合并流失的代码。也许您会发现在您的登录类中有几个方法需要合并，其余的可以共享 - 所以使用部分类或单独的 cpp 文件或将代码分解为辅助类或派生类 - 任何放置实现的方法将这些方法放入单独的文件中。然后你只需要在 shared 段代码被触及时进行合并，而不是不断地合并每个更改。随着时间的推移，您可能能够正确隔离和模块化非共享代码。

但是，我建议不要在合并必须是双向的任何情况下使用分支。

另一种方法是分支合并的相反方法。区分两个代码库，如果有差异，请将代码的两个变体放在一个条件编译块（#if ... #else ... #endif）中，这样您就可以从一组代码中编译两个变体源代码文件。这很丑陋，但允许您在没有任何分支或合并的情况下处理代码 - 您的开发人员仍然必须记住编译代码的两个变体以确保它们的更改在两个版本中都有效，但这比合并容易得多并重建这两个变体。同样，随着时间的推移，寻求将差异模块化，以便将它们最小化和/或合并以最小化影响。这种方法还可能允许将行为的某些部分更改为运行时而不是编译时选择，因此可以以不同且更有用的方式重用某些行为。使用一个不错的差异工具（例如 Araxis Merge），即使代码库很大，这也不应该是一个太糟糕的选择。几天的重构痛苦可以为您节省多年的麻烦。

我知道我在建议您要避免的事情，但是您越早承担解决技术债务的痛苦越好。在短期内通过分支来平滑症状会更容易，但永远无法解决根本问题……而技术债务的问题是，你离开的时间越长，情况就越糟。