我合并了一个拉取请求，GitHub 自动合并了另一个

Question

我在使用 GitHub 时遇到了一个奇怪的问题，想知道这是否是设计使然。我合并了一个拉取请求，有时一个单独的拉取请求也会被合并。这似乎是自动发生的。我注意到，对于 GitHub 自动合并的拉取请求，其分支已合并到我手动合并的拉取请求的分支中。

因此，例如，我有分支 A，我正在为其合并 PR。在合并分支 A 的 PR 之前，我将另一个分支分支 B 合并到分支 A 中。然后我合并分支A的PR，分支B的PR自动合并。

这是设计使然吗？这对我来说没有任何意义。为什么 GitHub 会假设分支 B 已准备好合并到 dev 中，只是因为我将它合并到分支 A 中？在我们的团队中，我们将分支相互合并，以尽量减少合并 PR 时的冲突。我还想知道是否可以在 GitHub 中的某处更改此行为。

Answer 1

是的，这是设计使然：当您将 B 合并到 A 时，您是在说 B 现在完全是 A 的一部分。然后，当您将A 合并到dev 时，您是在说A 完全是dev 的一部分。现在A 是dev 的一部分，B 是A 的一部分，因此B 是dev 的一部分。

如果您不希望在将A 合并到dev 时将B 合并到dev，您不得合并B进入A（例如你不能告诉git B是A的一部分）。

一件事可能会让你感到困惑：git 是关于源代码的，而不是 PR。 Github 将 PR 功能置于 git 实际跟踪的内容之上。当 Github 看到您已合并 PR 的代码时，它会关闭 PR。

您声明In our team, we merge branches into each other to minimize conflicts when PRs are merged.，听起来您实际上是在这样做向后。在您的示例中，通常要做的是当A 合并到dev 时，拥有B 的人将从dev 合并到B：从而解决B 上的任何合并冲突，因此当它们合并@987654350 @ into dev 实际合并变化只是功能B所需的变化，不会有任何合并冲突。