代码审查工作流程+ TFS中的功能分支

Question

我们正在开始使用功能分支，我们希望设置一个签到策略，该策略仅允许在具有相关代码审核时签入基线。

2012年新的代码审核工作流程非常好，因为您可以轻松地与开发人员和其他审阅者进行交互，并直接评论代码行。然而，似乎MS没有充分考虑用例，因为我们很容易遇到以下问题：

1. 开发人员定期进行功能分支登记/搁置和前向整合。

2. 当她想要整合该功能时，她会合并回基线，并要求对这些待处理的更改进行审核。

3. 审稿人发表了几条评论，现在她必须更改一些代码。她在哪里这样做？

选项1：返回分支，编辑代码并签入分支中的更改。撤消第一次合并的挂起更改。合并并再次请求审核。重复，直到没有更多评论。签入合并。 这不是很好，因为所有评论评论都在合并的待定更改中，并且她必须在她没有直接看到评论的分支上工作。

选项2：直接对合并的待处理更改进行修改。再次申请审核。重复，直到没有更多评论。签入合并。 如果她想继续在分支机构工作，她将不得不进行前向整合，因为审查中的变更不存在。

无论哪种方式，第二次审核总是非常烦人，因为您无法只看到第一次和第二次审核之间的变化，因为您总是与基线区分开来。

我在这里遗漏了什么吗？是否有其他选项可以审核审核中的更改？ 有没有人有更好的功能分支和代码审查方式？

新：使用VS和TFS2013，仍然没有任何改进：（

Answer 1

你没有遗漏任何东西。这是与Code Reviews实施方式相关的一个不幸的问题，它们只能链接到一个变更集，而不是一系列变更。

如果您的团队习惯于在其功能分支上进行高频率的签名，那么使用该工具审核每个单独的变更集可能会产生大量开销。但这将是我的建议。

有一个技巧，它并不理想，但它可能会有所帮助。您可以签出（在您的功能分支上）自上次签入以来更改的所有文件。然后请求审核。它将创建一个包含您的更改的搁置集，并将其与审阅相关联。这样您就不必在请求审核之前执行合并。在确定之前，请确保将main中的最新版本合并到功能分支中。这有两个主要缺点：

1. 虽然所有更改的文件都将链接到评论，但自上次评论后的更改不会自动突出显示。审稿人必须手动执行＆＃34;比较版本＆＃34;并选择比较目标。
2. 可以与评论相关联的文件限制为4000（从我的头顶开始），因此可以限制您可以作为一组查看哪些文件（我希望您不是将集成之间的4000多个文件更改为main）。