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