所以我最近读了这个blog post关于Github PR的堆叠差异，并一直试图遵循它。我遇到了一个问题，但我想要做一些堆积如山的PR，为此我无法访问上游回购，因此我无法推送任何分支。我在我的分叉回购中创建了一个初始分支，并开放了一个PR来对抗上游回购的主人。然后我创建了另一个以前一个分支为分支的分支。我做了一些代码更改，我想以第一个分支作为基础打开第二个PR，但我只能对自己的分叉回购而不是上游回购。有没有人遇到类似的问题？在过去，我可以访问上游回购，所以这不成问题，因为我可以将分支推向上游。我只是不确定在没有上游访问权限的情况下可能的解决方法。您可以使用分支存储库中的分支作为Github PR针对上游的基本分支吗？
然后我创建了另一个分支与该分支作为我的基地。我做了一些代码更改，我想开第二PR我的第一个分支为基础，但我只能这样做对我自己的分叉回购，而不是上游回购
是的，那是预期的：你比较你的针对上游分支进行工作，而您的尚未合并到原始回购中：它只存在于您的分支中。
一种解决方法是：
git cherry-pick (which is to say duplicate)从第一分支的提交，由于OP的结论是：
它并没有完全实现我的想法，因为PR包含了第一个分支的变化。
我认为这个问题最终是Github不允许我在PR上打一个分支，而PR已经打开的分支。
这当然是有道理的，因为该分支尚未合并到上游，因此不存在于上游回购仓库中，但似乎禁止了上游回购堆叠请求的可能性，推到。
我同意：理想情况下，PR应该独立于其他PR应用：维护者选择并选择哪些要接受，哪些拒绝。
我上面描述的是一种解决方法，但最终不是最佳实践。
的OP补充说：
我决定做的是开放我的第一个PR对上游主，我后来PR的反对我的分叉回购之前的分支。
然后，当一个PR登陆时，我可以轻松更改下一个PR的基本分支作为上游主设备，现在包含我以前的PR的更改。
那的确是更新对一个更新的起点/主现有的PR（现在包括其他合并PR）
感谢您的建议！我会试一试。看起来这可能会遇到问题，因为我在第一步创建的第二个分支将仅存在于本地。因此，我将无法将其作为我公关的基地。还没有尝试过，所以我可能会错过一些东西。 – jeromefroe
@jeromefroe是的，为了做PR，你需要先把你的第二个分支从你的本地仓库推到你的叉子上。这就是我在答案中的“推到你的叉子”的意思。 – VonC
我试过你的解决方法，它并没有完全实现我所想的，因为PR包含了第一个分支的更改。我相信这个问题最终是Github不会让我成为PR公司的上游分支机构，因为PR已经开放了。这当然是有道理的，因为该分支尚未合并到上游，所以在上游回购中不存在，但似乎禁止了上游回购的堆积拉动请求的可能性，这是人们无法推动的。 – jeromefroe
如果我理解正确的话，你创建了叉的一个分支，然后创建了一个正确的方法公关从那到主。如果你这样做，那么在上游没有“新”分支，但只有你的分叉。我不太清楚问题的第二部分，因为你为什么要将新的改变合并到新的分支？如果您对该分支做了更多更改，然后在分支上的同一分支上提交，并且您的PR将更新或创建新的PR（如果旧PR已关闭）或更好地创建新分支（基于旧PR /掌握如果prev。PR已合并）在您的叉子上，并创建一个新的PR – whoisthis
所以我想合并新的变化成upsteam主，但为了帮助使PR更具可读性我想有多个PR，每个PR构建在最后。因此，例如，第一个PR可能会引入我打算使用的接口，第二个PR可能会引入这些接口的具体实现，第三个PR可能会在回购的其他地方使用这些实现。因此，我不想将我的更改添加到我的第一个公关中，因为这将会形成一个大公关。另一方面，如果我从我的新分支创建一个新的公关，它将包含我第一个公关中的更改。 – jeromefroe