对于在同一项目中进行大量并发开发的小型开发团队而言，最佳分支和合并策略是什么？
我们需要能够在其他开发人员工作时轻松地将修补程序应用于 生产环境 版本 .
我正在从codeplex看TFS Branching Guidance guide，似乎无法弄清楚什么是我们的最佳选择 .
谢谢
对于在同一项目中进行大量并发开发的小型开发团队而言，最佳分支和合并策略是什么？
我们需要能够在其他开发人员工作时轻松地将修补程序应用于 生产环境 版本 .
我正在从codeplex看TFS Branching Guidance guide，似乎无法弄清楚什么是我们的最佳选择 .
谢谢
2 回答
如果不了解您的组织或团队的发展方式，很难（也许不可能）提出建议 .
在我们的组织中，我们的大多数开发都围绕发布进行组织，因此我们采用了“发布时分支”方法 . 这对我们很有用 . 我们还修复了错误，因此我们在 生产环境 线上实现了“分支功能”方法，以便修复错误 .
如果您有不同的人都在处理可能在不同时间进行 生产环境 的不同功能，那么“功能分支”方法可能会起作用 .
如果您都在使用相同的开发线，那么单个“开发”分支可能对您有用 .
我们花了几个月的时间来完成我们的分支策略（针对14个团队项目，大约80个开发人员和多个应用程序） . 我不认为这对于一个规模较小的组织来说需要花费很长时间，但是肯定会花一些时间来考虑这个问题，并考虑引入一些外部专业知识来为您提供指导 .
除了Robaticus之外，您还需要弄清楚为什么要进行并行开发 .
在我看来，这完全取决于你想要分离的东西
如果您进行并行开发，因为开发了多个功能，则取决于功能是否需要在同一个包中发布（版本/发布/给它命名）以及是否希望不同的功能不集成在开发过程中彼此相处 . 当不同的功能相互干扰时，后者非常重要，并且您只想在合并两个功能时花时间进行集成 . 如果由于上述任何原因需要隔离，则在进行集成测试之前，您将在一个版本中包含多个分支 .
如果你进行并行开发是因为你想支持多个版本，那么你需要知道需要支持多少个版本（你需要支持多少个在 生产环境 中推出的版本，你有多少版本在pre - 生产环境 等） . 在这种情况下，建议您需要支持每个版本的分支 . 听起来您需要为您的组织制定此分支策略 .
它还取决于您分支的文件类型 . 如果您有SSIS或SSRS文件（或任何其他基于XML的文件），二进制文件或任何不容易文本的文件（与C＃相反），那么从两个不同的分支合并文件并不容易 . 然后，您需要手动参与实际合并这些文件！
正如Robaticus已经说过的那样，我们需要有关您特定场景的更多信息，以提供更详细的指导 .