我们开始使用功能分支，并且我们希望设置一个签入策略，该策略仅允许在具有关联的代码审查时签入基线。
2012年新的代码审查工作流程非常好，因为您可以轻松地与开发人员和其他审阅者进行交互，并直接评论代码行。然而，似乎MS没有充分考虑用例，因为我们很容易遇到以下问题：
选项1：返回分支，编辑代码并签入分支中的更改。撤消第一次合并的挂起更改。合并并再次请求审核。重复，直到没有更多评论。签入合并。这不是很好，因为所有评论评论都在合并的待定更改中，并且她必须在她没有直接看到评论的分支上工作。
选项2：直接对合并的挂起更改进行编辑。再次申请审核。重复，直到没有更多评论。签入合并。如果她想继续在分支机构工作，她将不得不进行前向整合，因为审查的变化不存在。
无论哪种方式，第二次审查总是非常烦人，因为您无法只看到第一次和第二次审核之间的变化，因为您总是在与基线进行区分。
我在这里错过了什么吗？是否有其他选项可以审核审核中的更改？有没有人有更好的功能分支和代码审查方式？
新：使用VS和TFS2013，仍然没有改进:(
你没有遗漏任何东西。这是与Code Reviews实施方式相关的一个不幸的问题，它们只能链接到一个变更集，而不是一系列变更。
如果您的团队习惯于在其功能分支上进行高频率的签入，那么使用该工具审查每个单独的变更集可能会产生大量开销。但这将是我的建议。
有一个技巧，它不是理想的，但它可能有所帮助。您可以签出（在您的功能分支上）自上次签入以来更改的所有文件。然后请求审核。它将创建一个包含您的更改的搁置集，并将其与审阅相关联。这样，您无需在请求审核之前执行合并。在确定之前，请确保将main中的最新版本合并到功能分支中。这有两个主要缺点：