你遇到了这种情况：

branch-A
                          v
              1---2---3---4
             /
O---O---O---O
            ^
          master

然后你做了这个：

branch-A       branch-B
                          v               v
              1---2---3---4---5---6---7---8
             /
O---O---O---O
            ^
          master

要总结当前状态，请执行以下操作：

• A到master的pull请求将显示A和master之间的差异，这实际上是提交1-4
• B到master的pull请求将显示B和master之间的差异，这实际上是提交1-8，因此包括来自A的尚未合并到master中的所有更改

如果你现在决定完成A的pull请求，你会遇到这样的场景：

branch-A       branch-B
                          v               v
              1---2---3---4---5---6---7---8
             /             \
O---O---O---O---------------X
                            ^
                          master

其中X现在是合并提交。在此之后，没有其他更改或操作，如果您重新访问B的pull请求，它现在应该（再次，仍然）显示B和master之间的差异，但现在它只包括提交5-8。
如果你先完成了B的pull request，你会得到这样的结果：

branch-A       branch-B
                          v               v
              1---2---3---4---5---6---7---8
             /                             \
O---O---O---O-------------------------------Y
                                            ^
                                          master

如果你现在重新访问A的拉取请求，根据工具的不同，你要么会看到一个空的diff，要么拉取请求可以被标记为已完成（我似乎记得Bitbucket for Enterprise使用这种方法），因为A中的所有更改都已经成功合并。
总结一下：

TL;DR：您的B分支实际上没有受到影响，但它和master之间的差异最初也会包括来自A的所有更改，但在完成A的PR后，它只会显示B和master之间的差异，而不再显示来自A的更改，因为它们已经合并。你的“我的看法”这段话是正确的。

首先要理解的是，pull requests根本不是Git的功能。它们是某些Git托管网站所做的事情，并且它们以不同的方式做到这一点。
让我们将我们的考虑限制在GitHub上。GitHub以一种非常方便和连贯的方式处理这种情况。
为了示例的目的，假设你有一个分支branchA，你将它作为一个pull request提交给GitHub，以便合并到main中。然后在branchA的末尾创建一个新的分支branchB，并在那里继续开发。这种情况经常发生在我身上，所以我对它的工作原理有很深的经验。
有两种可能的理想结果：

理想路径1

可能发生的第一件理想的事情是，当您仍在处理branchB时，branchA的PR被接受并合并。然后，您只需将branchB重定基到main，如下所示：

git rebase --onto main branchA branchB

该咒语将branchB提交从branchB与branchA的分歧点剥离，并将它们附加到main的末尾。您可以继续工作，直到准备好提交PR，然后将其提交以合并到main中。由于branchB现在直接来自main，PR将只包含您在branchB上所做的提交，这正是您想要的。
请注意，即使在接受branchA * 时添加了更多提交，它也能正常工作。

理想路径2

现在，假设您在branchA PR尚未被接受的情况下完成了branchB工作。没问题;继续并将branchB的PR提交到GitHub，但是当您这样做时，当您在GitHub Web界面中构建新PR时，告诉GitHub * 您想要将branchB合并到branchA *（而不是main）。通过这样做，两件美妙的事情发生了：

• branchB的PR只包含您在branchB上所做的提交，这正是您想要的。
• 如果branchA PR现在被接受并合并，GitHub * 会神奇地更改branchB PR*，以便它现在要求合并到main！此外，PR still 只包含您在branchB上所做的提交！

即使branchA作为接受的一部分获得了更多的提交，它也能正常工作。但是，在这种情况下，在branchA PR被接受并合并之后，您可能希望将main合并到branchB（“反向合并”）中，以获取（或者协调）最新的更改。

我的看法是，如果pull request approver合并了branchA，那么我的branchB pull request就已经包含了branchA的提交，而diff实际上只会显示branchA和branchB之间的更改
这取决于您如何设置BranchB的合并请求。如果您选择将其合并到master中，而BranchA尚未合并，则您将看到所有更改。但是你也可以创建合并请求，说将BranchB合并到BranchA，然后你只看到从BranchB到BranchA的更改。
您始终可以更改分支将合并到哪个分支。因此，假设您首先设置Pull Request，将BranchB合并到BranchA中，只查看差异。如果BranchA被合并到master，你可以重定BranchB的基，或者将master合并到BranchB。

根据Lasse的回答，如果在创建B之后将更改合并到A中，然后在A合并到master之前再次将A合并到B中，那么一切都将按预期工作，并在他的回答中显示。是这样吗？
不完全是没有变化被“合并到A中”。
A被推送为PR，这意味着请求将 * A的更改 * 合并 * 为 * master。
Lasse V. Karlsen的answer表明B不受此影响。
如果B被推送到它自己的PR（请求将B的更改合并到master），您最初会看到来自A * 和 * B的更改。
但是一旦A被合并到master，B的PR将自动更新，并且将仅反映B的更改（将被合并到master），而不再是A的更改（* 已经 * 合并到master，因为它自己的PR已经完成）。