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