我的.NET WPF项目使用的源代码控件是TFS。该项目的客户都是公司内部的。在不久的将来，由于一系列特殊要求，我们将只向一个客户发布一个版本。源代码管理：支持多个版本的软件
因此，我们计划在TFS中创建另一个分支并纳入这些要求。问题在于客户可能需要长期支持此版本，并且可能只需要在产品中添加缺陷修复程序，而不是将任何新功能添加到主分支中。尽管目前这种方式非常易于管理，但我担心的是，1 - 2年后，我们最终可能拥有多个源代码分支，这将导致支持n个版本的可维护性问题。
您能否建议一些方法来保持整个情况的可管理性，或者我们创建多个分支机构的方法本身是否是错误的。
我会说这个问题是关于一个企业，然后关于使用的技术。
您确定这是您的唯一一位需要贵公司这种待遇的客户吗（我认为这是重要客户）？
是的。在这种情况下只需创建一个分支。设置自动测试脚本。上每承诺您提供的主分支也应该存在int 客户分支进行合并。运行你每晚脚本是否完整
号我要说不作分支，在这一点上（在你到底想怎么样多少分支机构管理现代化的..），并在代码使用配置选项。这意味着明确区分一个客户或另一个客户可用的功能。这些功能可以基于应用程序配置文件中的某些配置选项提供。如果你想让这些东西更加棘手，因为客户端可以操作文件，可以创建许可证类型（密钥），他们可以计算散列汇总不共享功能的可用性。
不幸的是分支在集中式代码版本控制系统中总是令人头痛。在分布式系统中，它的管理方式要好得多，但顺便说一下，完全避免冲突（尤其是长期运行）在两种情况下都几乎是不可能的。
祝你好运。
我建议你为发布的版本创建分支，并且在你从该分支创建的每个后续发行版上（因为你只是在进行错误修复），每次从“bug修复分支”发布时，都不要重新分支，但创建一个标签，以便您可以轻松地进行参考。
这与我们目前的计划相同。但我担心的是，一两年后，可能会有很多分支从主分支走出来，所有分支都有特性和错误修复混合匹配 – ganeshran 2012-03-28 18:34:36
@Jason：并且不要忘记合并您的发布分支'在分支开始偏离太多之前，bug修复到主干/主分支。 – 2012-03-28 18:37:03
@ ganeshran为了实现这一目标，确保您的客户在需要重大功能工作时从主分支开始获得新版本。那么你可以从那时起忘记他们以前的分支。 – 2012-03-28 18:40:14
我的建议是，你可以通过Visual Studio ALM Rangers来研究TFS分支指南。这只是一些阅读，但是很好，你应该能够找到适合你的场景 - 而且在使用TFS时是明智的。您可以在这里找到：http://vsarbranchingguide.codeplex.com/
这个配置选项听起来是个不错的主意。我会试试这个。 – ganeshran 2012-03-29 12:24:47