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

Question

我们开始使用功能分支,并且我们希望设置一个签入策略,该策略仅允许在具有关联的代码审查时签入基线.

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

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

选项2:直接对合并的挂起更改进行编辑.再次申请审核.重复,直到没有更多评论.签入合并.如果她想继续在分支机构工作,她将不得不进行前向整合,因为审查的变化不存在.

无论哪种方式,第二次审查总是非常烦人,因为您无法只看到第一次和第二次审核之间的变化,因为您总是在与基线进行区分.

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

新:使用VS和TFS2013,仍然没有改进:(

Answer 1

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

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

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

虽然所有更改的文件都将链接到审阅，但自上次审阅以来的更改不会自动突出显示。审阅者必须手动执行“与版本比较”并选择比较目标。
可以与审阅相关联的文件数量限制为 4000 个（从我的角度来看），因此这可能会对您可以作为一个组审阅的文件构成限制（我希望您不会在两次审阅之间更改 4000 多个文件）集成到 main 中）。