【发布时间】：2011-04-29 08:11:08
【问题描述】：
对于在同一个项目上进行大量并发开发的小型开发团队来说，最好的分支和合并策略是什么？
我们需要能够在其他开发人员工作的同时轻松地将修补程序应用于生产版本。
我正在查看来自 codeplex 的 TFS Branching Guidance guide，但似乎无法弄清楚什么是最适合我们的选择。
谢谢
【问题讨论】：
标签： asp.net architecture tfs
【发布时间】：2011-04-29 08:11:08
【问题描述】：
在不了解您的组织或团队的发展方式的情况下，很难（甚至不可能）提出建议。
在我们的组织中，我们的大部分开发工作都是围绕发布进行的，因此我们采用了“发布时分支”的方法。这对我们很有用。我们还进行错误修复，因此我们在生产线上实施了“功能分支”方法来修复错误。
如果您有不同的人都在开发可能在不同时间投入生产的不同功能，那么“功能分支”方法可能会奏效。
如果你们都在同一条开发线上工作，那么一个“开发”分支可能适合你。
我们花了几个月的时间才最终确定了我们的分支策略（针对 14 个以上的团队项目、大约 80 个开发人员和多个应用程序）。我不认为较小的组织需要这么长时间，但一定要花一些时间思考这个问题，并考虑引入一些外部专家来为您提供指导。
【讨论】：
除了 Robaticus 之外，您还需要弄清楚为什么要进行并行开发。
在我看来，这完全取决于您要隔离的内容
如果因为要开发多个功能而进行并行开发，这取决于功能是否需要在同一个包中发布（版本/发布/给它一个名称）以及您是否想要不同的功能在开发过程中不要相互集成。当不同的功能相互干扰并且您只想在合并两个功能时花时间在集成上时，后者很重要。 如果您出于上述任何原因需要隔离，您可以在一个版本中拥有多个分支，在进行集成测试之前将它们合并。
如果你做并行开发是因为你想支持多个版本，那么你需要知道你需要支持多少个版本（你需要支持多少在生产中推出的版本，多少个版本你有预生产等）。在这种情况下，建议每个版本都有一个您需要支持的分支 听起来您需要为您的组织制定这种分支策略。
这还取决于您要分支的文件类型。如果您有 SSIS 或 SSRS 文件（或任何其他基于 XML 的文件）、二进制文件或任何不是简单文本的文件（与 C# 相比），那么合并来自两个不同分支的文件并不容易。然后，您需要手动参与才能真正合并这些文件！
正如 Robaticus 已经说过的，我们需要有关您的特定场景的更多信息，以提供更详细的指导。
【讨论】：