我们将 TFS 2010 用于新项目，我正在寻找有关在团队开发时使用策略签入选项的最佳实践和知识/经验。我已经找到了有关所有这些的信息，但关于最佳实践以及开发团队对策略的看法和经验的信息并不多，他们使用过，也许应该使用。
- 您使用了哪些策略？
- 你的经历是什么？
- 你会推荐什么？
例如，您是否使用过Microsoft最低推荐规则，并且是否全部使用它们？
感谢您的信息和经验。
最基本的签到政策是：
- 注释策略 - 所有签入都需要注释。
- 工作项关联 - 这应该是必需的，因为没有它，就无法将更改集分组到特定的工作流。您需要能够执行此操作才能批量合并和回滚更改。
- 门控签入 - 虽然不是这样的策略（需要创建门控版本），但它会阻止开发人员签入破坏构建的代码。如果在代码库中创建了链接生成，则可以确保解决方案永远不会因再次签入而中断。我已经做到了，它有效。
还有许多其他（我们使用双子座项目关联策略），您可以像我们一样编写自己的策略。这并不难，您可以定制它们以适应。
这更像是一个讨论问题，这不是 StackOverflow 通常想要的问题类型，但我会咬。
对我来说有意义的政策是：
- 构建策略
- 此策略可防止在有人中断生成后出现失败生成的生成队列。实际上，系统会警告您构建当前已损坏，以便有人可以在继续之前修复构建。
- 工作项关联
- 我们需要工作项关联，以确保我们可以跟踪签入到正在完成的工作，以及测试用例。
- 工作项查询
- 我们希望人们从当前的冲刺/迭代中选择他们的工作。因此，验证人们签入的工作是否实际上是预先批准的工作非常方便。
- 自定义路径策略
- 我们偶尔会在包含多个项目的团队项目中使用此策略，并且我们希望提高一个项目的质量或安全性，但不想打扰另一个项目。或者为了防止在当前版本分支上进行某些签入，但不希望在仍在维护的旧版本上采用如此严格的策略。
我们验证了一些事情，您可以通过签入策略执行，而不是使 CI 生成失败。这样做主要是为了节省开发人员机器上的时间。
- 代码分析策略。
- 我们没有为此使用签入策略，而是使用 CI 构建，如果某些代码分析规则被破坏，该构建将失败。这允许开发人员在每次构建时跳过代码分析。人们将很快学会如何防止这些规则触发。
我们不会使用任何其他政策。我们有时会使用"更改集需要注释"策略，但大多数团队在一段时间后实际上不需要为此提供策略。大多数人都不喜欢对签入发表任何评论，这自行解决。
我们有几个项目进行了时间跟踪（针对MSF CMMI），我们使用自定义策略来确保人们在每次签到时更新他们的工作时间。
我们不会使用任何策略来强制实施代码覆盖率或警告数。如果需要，可以通过生成过程自定义将这些添加到生成中。
我们在需要额外验证的分支机构上使用门控签到。例如发布分支和随后自动部署的分支。
我们通常允许开发人员绕过任何签入策略而不会受到处罚。门控签入也是如此。开发人员有责任明智地使用这些权利。中断部署是您在被团队;)注意到之前不能经常做的事情。
也有一些有趣的自定义策略，但我知道只有少数人真正使用这些策略。
- 仅合并策略
- 此策略允许您指定几个分支，这些分支只能接收另一个分支上已签入工作的合并。
- 禁止模式策略
- 我有时会使用这些来确保没有
/bin/debug、.exe或.dll签入 TFS 中的//src/文件夹。
- 我有时会使用这些来确保没有
还有来自第三方的更多策略，但我从未使用过这些策略。其中包括：
- 签入策略包和该页面列出了一些我从未使用过的额外策略。
不使用太多第三方策略的原因之一是所有团队成员都需要在他们的机器上安装策略。Team Foundation Server Power Tools 可以帮助您完成分发，但默认情况下，这些工具不会在所有开发人员工作站上部署和配置。
也可以博客形式提供。
尝试每个签入策略，看看它们是否为您的团队提供价值。
我们的某些团队项目只需要签入注释。有些需要注释和工作项。有些需要成功的构建。这完全取决于团队的需求。
不要试图遵循别人的最佳实践。确定在您的环境中有效的方法。