.net 源代码管理：支持软件的多个版本

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

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

尽管目前这是可以管理的，但我担心在接下来的1-2年内，我们可能会有多个源代码分支，这将导致支持n个版本的可维护性问题

---

您能否建议如何保持整个情况的可控性，或者我们创建多个分支本身的方法一开始是否是错误的。

我建议您为发布的版本创建分支，并在从该分支生成的每个后续版本上创建分支（因为您只进行错误修复），每次从“bug fix branch”发布时，不要重新分支，而是创建一个标记，以便您可以方便地引用。

我想说，问题更多的是关于业务，而不是要使用的技术

你确定这是你公司唯一需要这种待遇的客户吗（我想这是一个重要的客户）

• 对。在这种情况下，只需做一个分支。设置自动测试脚本。在您对主分支所做的每一次提交中，也应该在客户分支中进行合并。运行夜间脚本以检查完整性

• 不，我会说不要做分支，在这一点上（在最后你要管理多少分支…），并在代码中使用配置选项。这意味着对一个客户或另一个客户的可用功能进行明确的分离。这些功能可以根据应用程序配置文件中的某些配置选项来提供。如果你想让事情变得更加棘手，因为客户端能够操作文件，那么你可以发明许可证类型（密钥），这些许可证类型（密钥）通过计算哈希聚合而不是共享特性的可用性

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

---

祝您好运。

我的建议是您学习Visual Studio ALM Rangers提供的TFS分支指南。这是相当多的阅读，但很好，您应该能够找到适合您的场景，并且在使用TFS时是明智的。您可以在这里找到它：

这与我们目前的计划相同。但我担心的是，在接下来的1-2年内，可能会有很多分支从主分支出来，所有分支都具有混合和匹配的功能和bugfixes@Jason：在分支开始出现太多分歧之前，不要忘记将发布分支的错误修复合并到主干/主分支中。@ganeshran实现了这一点，当您的客户需要重要的功能工作时，请确保他们从主分支获得新版本。从那时起，你就可以忘记他们以前的分支了。@ganeshran我认为这是你最好的方法，如果你打算支持一个产品的多个版本来修复bug，并且功能没有转移到另一个版本。imho的替代方案将更加繁琐，最终这些分支/版本中的一些应该消失，在下一个版本中提供足够的功能和必须具备的功能，因此在保留真正的旧版本时几乎没有动机，比如说为什么在v5有这么多功能时使用v1，或者v1在Win2000 32位上运行，但是他们现在运行的是Win7 64位：）@jdv Jandavan我想任何研究分支（或者声称已经在做分支）的人都知道这个基本步骤：）这个配置选项听起来是个好主意。我试试这个。