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

Question

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

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

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

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

Answer 1

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

Answer 2

我想问的问题是关于一项关于使用技术的业务。

您确定这是您唯一需要贵公司处理此类治疗的客户（我认为这是重要客户）吗？

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

• 没有。我会说不要制作分支，在这一点（最后你将管理多少分支当代..）并在代码中使用配置选项 。这意味着明确分离一个客户或另一个客户可用的功能。可以根据应用程序配置文件中提供的某些配置选项提供这些功能。如果您想让这些东西更加棘手，因为客户端能够操作文件，可以发明计算散列聚合不共享功能的许可类型（密钥）。

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

祝你好运。

Answer 3

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