源代码控制：支持软件的多个版本答案

【问题标题】：Source Control: Supporting multiple versions of a software源代码控制：支持软件的多个版本
【发布时间】：2012-03-28 18:26:13
【问题描述】：

我的 .NET WPF 项目使用的源代码控制是 TFS。该项目的客户都是公司内部的。在不久的将来，由于一系列特殊要求，我们将只向一个客户发布一个版本。

因此我们计划在 TFS 中创建另一个分支并整合这些要求。问题是客户可能需要对此版本的长期支持，并且可能只希望将缺陷修复程序纳入产品，而不是我们在主分支中合并的任何新功能。

虽然目前这很容易管理，但我担心 1-2 年后，我们可能最终会拥有多个源代码分支，这将导致支持 n 个版本的可维护性头痛。

您能否提出一些方法来使整个情况保持可控，或者我们创建多个分支的方法本身是否首先是错误的。

【问题讨论】：

【解决方案1】：

我想说这个问题更多的是关于企业，而不是关于使用的技术。

您确定这是您唯一需要贵公司提供这种待遇的客户（我想这是重要客户）吗？

是的。在这种情况下，只需创建一个分支。设置自动化测试脚本。在每个上提交的 主分支 上也应该存在 int customer 分支 进行合并。运行您的夜间脚本以检查完整性
没有。我想说不要创建分支，在这一点上（最后你要管理多少个分支......）并在代码中使用配置选项。这意味着明确区分可供一位客户或另一位客户使用的功能。这些功能可以根据应用程序配置文件中可用的某些配置选项来使用。如果您想让这些东西变得更棘手，因为客户端能够操作文件，可以发明计算哈希聚合不共享功能可用性的许可证类型（密钥）。

不幸的是，在集中式代码版本控制系统中，分支总是令人头疼。在分布式系统中，它的管理方式要好得多，但顺便说一句，完全避免冲突，尤其是从长远来看，在这两种情况下几乎是不可能的。

祝你好运。

【讨论】：

【解决方案2】：

我建议您为已发布版本创建分支，并且在您从该分支创建的每个后续版本中（因为您只是进行错误修复），每次从该“错误修复分支”发布时，不要' t 重新分支，但创建一个标签，以便您可以轻松引用。

【讨论】：

这与我们目前的计划相同。但我担心的是，1-2 年后，可能会有很多分支从主分支出来，所有分支都混合了功能和错误修复
@Jason：别忘了在分支开始分歧太大之前将发布分支的错误修复合并到主干/主分支中。
@ganeshran 要实现这一点，请确保您的客户在需要重要功能工作时从主分支开始获得新版本。然后你就可以忘记他们以前的分支了。
@ganeshran 我认为如果您要支持产品的多个版本以进行错误修复并且功能不会转移到其他版本，那么这是您的最佳方法。替代方案会更麻烦恕我直言，最终其中一些分支/版本应该会消亡，在下一个版本中添加足够的功能和必须具备的功能，因此几乎没有动力留在真正的旧版本中，比如说为什么在 v5 有这么多的时候使用 v1，或者 v1 在 Win2000 32Bit 上运行，但他们现在正在运行 Win7 64bit :)
@jdv-JandeVaan 我假设任何研究分支（或声称已经在进行分支）的人都已经知道基本步骤:)

【解决方案3】：

我的建议是您学习 Visual Studio ALM Rangers 的 TFS 分支指南。这是相当多的阅读，但很好，你应该能够在那里找到适合你的场景 - 并且在使用 TFS 时是可取的。你可以在这里找到它：http://vsarbranchingguide.codeplex.com/

【讨论】：