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

Question

我们开始使用功能分支，并且我们希望设置签入策略，只有在他们有相关代码审查时才允许签入基线。

2012年新的代码审查工作流程非常好，因为您可以轻松地与开发人员和其他审阅人员交互，并直接评论代码行。尽管如此，它看起来像MS没想到使用情况完全是因为我们很容易碰到以下问题：

1. 开发人员处理的特性分支签入/货架和前瞻性整合定期。

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

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

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

选项2：直接对未决的合并更改进行编辑。再次请求审查。重复，直到没有更多的评论。检入合并。 如果她想继续在分支上工作，她将不得不进行前瞻性整合，因为审查中的更改不存在。

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

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

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

Answer 1

你不会错过任何的是代码审查是实现方式相关联的不幸的问题，它们只能链接到一个如果您的团队习惯于在他们的功能分支上进行高频签名，那么使用该工具检查每个单独的更改集可能会产生很大的开销，但这将是我的推荐

有一招，这并不理想，但它可能有所帮助。您可以签出（在您的功能分支上）自上次签入后更改的所有文件。然后请求审查。它会根据您的更改创建一个shelveset并将其与审阅相关联。这样，在请求审查之前，您不必执行合并。只需确保在将此技巧拉入前，将最新版本从主要版本合并到您的功能分支中。这有两个主要缺点：

1. 尽管所有更改的文件都将链接到评论，但上次评论后的更改不会自动突出显示。审阅者将不得不手动进行“比较版本”并选择比较目标。
2. 有一个限制4000（从我的头顶）文件，可以与审查相关联，这可能会限制哪些文件，你可以作为一个组审查（我希望你没有改变4000 +集成之间的文件转换为主文件）。