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

Posted 2021-05-05

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

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

1. 开发人员定期进行功能分支登记/搁置和前向整合。
2. 当她想要集成该功能时，她会合并回基线并请求对这些待处理的更改进行审核。
3. 审稿人发表了几条评论，现在她必须改变一些代码。她在哪里这样做？

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

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

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

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

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

答案

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

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

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

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