如何处理多个PULL请求？

Question

在第一个请求被接受之后，我是否应该拒绝所有的PULL REQUETS，以便Hey可以将接受的PULL REQUEST与他们的更改合并为最新的？

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

说我有一个MASTER分支，我创建了两个PBI，以完成两项工作。

对于这些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的生成结果设置为在更改主服务器后立即过期： 这意味着该构建将再次运行，这意味着您不仅会捕获合并冲突，而且还会捕获PR与更新后的母版合并可能导致的错误。仅当您具有适当的单元测试并且已在PR验证中启用了这些单元测试时。

Answer 2

您不必担心拒绝一个或另一个请求请求。

一个拉取请求被接受后，如果VSTS包含与从第一个拉取的项目冲突的任何内容，它将在第二个拉取请求上显示一个红色大错误。这将阻止拉请求在冲突解决之前完成。

我敢肯定，如果发生合并冲突，您甚至可以将VSTS配置为向创建PR的人发送电子邮件，以便他们可以更新PR。

对于结构良好的应用程序，合并冲突不是很常见，因此这可以很好地表明应用程序体系结构的质量。