我是否应该在接受第一个 PULL REQUEST 后拒绝所有 PULL REQUEST，以便他们可以将已接受的 PULL REQUEST 与他们的更改 merge 以保持最新？
我在 merge 多个 pull 请求时遇到问题。我在 VSTS 工作。
假设我有一个 MASTER 分支，我创建了两个 PBI 来完成两项工作。
对于这些 PBI，我为每个创建了一个单独的分支。
在这些 PBI 上完成工作后，每个人都会创建一个 PULL REQUEST 以在 merge 回 MASTER 之前进行审查。
在 PULL REQUEST 时，两个分支实际上都与 MASTER 保持同步，因为它们已将 MASTER merge 到它们的 PBI 分支上。
现在，当我接受其中一个 PULL REQUESTS 并将其 merge 到 MASTER 时，另一个 PBI 现在位于 MASTER 分支之后。
这只是拒绝后来的 PBI 并要求它们更新的情况吗？当它们是最新的时，我会以先到先得的方式接受它们(只要它们是正确的)。
我看到的问题是，如果有“n”个 pull 请求，我将总是不得不拒绝“n-1”个 pull 请求，因为当我接受第一个时，其余的就没有了日期。
上图显示了 MASTER 分支(绿色)和两个特征分支(橙色和蓝色)。两者都提出了 PULL REQUEST，当其中一个被接受时，另一个就过时了。
最佳答案
第一个 pull 请求被批准，首先被 merge 到主分支。后续的 pull request，不需要在自己的分支上 merge master 分支，除非有 merge 冲突。因此，它们不会过时，除非它们也处理同一组文件。
当您在 pull 请求中看到 merge 冲突时，请立即要求开发人员修复 merge 冲突并更新 pull 请求，并在稍后审查 pull 请求。在这种情况下，后续的 pull 请求开发人员已经过时，他必须在 merge 冲突修复中修复它们。
因此，无论哪个 pull 请求在先前的 pull 请求之后进行，都必须处理与 merge 冲突相关的问题。
此外，如果您在分支策略中使用Build validation 策略，您可以将 PR 的构建结果设置为在 master 更改时立即过期:
这意味着构建将再次运行，这意味着您不仅可以捕捉到 merge 冲突，还可以捕捉到将 PR 与更新的 master merge 可能引入的错误。前提是您有适当的单元测试，并且在您的 PR 验证中启用了这些单元测试。
关于git - 如何处理多个 PULL REQUESTS？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51629464/