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

Question

我们开始使用功能分支，并且希望设置一个 checkin 策略，仅当基线具有关联的代码审查时才允许 checkin 。

2012 年新的代码审查工作流程非常好，因为您可以轻松地与开发人员和其他审查者进行交互，并直接注释代码行。尽管如此，微软似乎并没有充分考虑用例，因为我们很容易遇到以下问题:

1. 开发人员定期进行功能分支 checkin /搁置和前向集成。

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

3. 审阅者提出了一些意见，现在她必须更改一些代码。她在哪里这样做？

选项 1:返回分支，编辑代码并 checkin 分支中的更改。撤消第一次合并的待处理更改。合并并再次请求审核。重复直到没有更多评论。 checkin 合并。这不太好，因为所有审核评论都在合并的待处理更改中，而她必须在无法直接看到评论的分支上工作。

选项 2:直接对合并的待处理更改进行编辑。再次请求审核。重复直到没有更多评论。 checkin 合并。如果她想继续在该分支工作，则必须进行前向集成，因为审核中的更改不存在。

无论哪种方式，第二次审查总是非常烦人，因为你无法只看到第一次和第二次审查之间的变化，因为你总是与基线进行比较。

我在这里遗漏了什么吗？是否有其他选项允许查看审核中的更改？有谁有更好的功能分支和代码审查方法吗？

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

Answer 1

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

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

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

1. 虽然所有更改的文件都会链接到审核，但自上次审核以来的更改不会自动突出显示。审核者必须手动执行“与版本比较”并选择比较目标。
2. 可与审阅相关联的文件数量限制为 4000 个(根据我的想象)，因此这可能会对您作为一个小组审阅的文件构成限制(我希望您不要更改 4000 个文件) + 集成到 main 之间的文件)。