我在使用 GitHub 时遇到了一个奇怪的问题，想知道它是否是设计使然。我合并了一个拉取请求，有时一个单独的拉取请求也会被合并。这似乎是自动发生的。我注意到，对于 GitHub 自动合并的拉取请求，它的分支已合并到我手动合并的拉取请求的分支中。
因此，例如，我有分支A，我正在为其合并 PR。我将另一个分支，分支B合并到分支A中，然后再合并分支A的PR。然后，我合并分支A的 PR，分支B的 PR 会自动合并。
这是设计使然吗？这对我来说没有任何意义。为什么 GitHub 会因为我将分支B合并到分支A中就认为分支已准备好合并到dev中？在我们的团队中，我们将分支相互合并，以最大程度地减少 PR 合并时的冲突。我还想知道是否可以在 GitHub 中的某个地方更改此行为。
是的，这是设计使然：当您将B合并到A时，您是在说B现在完全是A的一部分。然后，当您将A合并到dev时，您是在说A完全是dev的一部分。现在传递A是dev的一部分，而B是A的一部分，因此B是dev的一部分。
如果你不希望B在将A合并到dev时被合并到dev，你一定不能B合并到A中(例如，你不能告诉 gitB是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上的任何合并冲突，因此当它们B合并到dev时，实际的合并更改只是功能B所需的更改， 并且不会有任何合并冲突。