如何处理多个 PULL REQUESTS？

Question

我是否应该在第一个被接受后拒绝所有 PULL REQUESTS，以便他们可以将接受的 PULL REQUEST 与其更改合并以保持最新？

我在合并多个拉取请求时遇到问题。我在 VSTS 工作。

假设我有一个 MASTER 分支，我创建了两个 PBI 来完成两项工作。

对于这些 PBI，我为每个创建了一个单独的分支。

当这些 PBI 上的工作完成时，每个人都会创建一个 PULL REQUEST 以在合并回 MASTER 之前进行审查。

在 PULL REQUEST 时，两个分支实际上都与 MASTER 保持同步，因为它们已将 MASTER 合并到它们的 PBI 分支上。

现在，当我接受其中一个 PULL REQUESTS 并将其合并到 MASTER 时，另一个 PBI 现在位于 MASTER 分支之后。

这只是拒绝后来的 PBI 并要求他们更新的情况吗？当它们是最新的时，我会以先到先得的方式接受它们（只要它们是正确的）。

我看到的问题是，如果有“n”个拉取请求，我将总是不得不拒绝“n-1”个拉取请求，因为当我接受第一个拉取请求时，其余的就过时了。

上图显示了 MASTER 分支（绿色）和两个特征分支（橙色和蓝色）。两者都提出了 PULL REQUEST，当一个被接受时，另一个就过时了。

Answer 1

第一个拉取请求被批准，首先合并到主分支。后续的拉取请求，不需要在他们的分支上合并 master 分支，除非有合并冲突。因此，它们不会过时，除非它们也处理同一组文件。

当您在拉取请求中看到合并冲突时，请立即要求开发人员修复合并冲突并更新拉取请求，并在稍后审查拉取请求。在这种情况下，后续的拉取请求开发人员已经过时，他必须在合并冲突修复中修复它们。

因此，无论在先前的拉取请求之后进行哪个拉取请求，都必须处理与合并冲突相关的问题。

此外，如果您Build validation在分支策略中使用该策略，则可以将 PR 的构建结果设置为在 master 更改时立即过期： 这意味着构建将再次运行，这意味着您不仅会捕获合并冲突，还会捕获因将 PR 与更新的主文件合并而可能引入的错误。仅当您有适当的单元测试并在 PR 验证中启用这些测试时。