7

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

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

  1. 开发人员定期处理功能分支签入/搁置和前向集成。

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

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

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

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

无论哪种方式，第二次审查总是很烦人，因为你无法只看到第一次和第二次审查之间的变化，因为你总是与基线不同。

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

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

4

1 回答 1

2

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

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

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

  1. 虽然所有更改的文件都将链接到审核，但自上次审核以来的更改不会自动突出显示。审阅者必须手动执行“与版本比较”并选择比较目标。
  2. 可以与评论相关联的文件限制为 4000 个（从我的脑海中），因此这可能会限制您可以作为一个组查看的文件（我希望您不会更改 4000+ 个文件）集成到 main 中）。
于 2015-10-22T18:20:15.433 回答