我有一套公司 API 的文档，基于来自 TripIt 的优秀 Slate 框架。根据指示，我分叉了他们的存储库并继续对其进行自定义。那叉子就在这里。
令人讨厌的是，当我组织中的贡献者提出新的拉取请求时，Github“比较更改”屏幕上的“基本分支”默认为 TripIt 的存储库，而不是我的分支。他们不止一次将拉取请求发送到错误的地方。告诉人们“不要这样做”并不是一个特别可靠的解决方案。如何设置 PR 基于我的分叉的默认值？
git pull
，并确保您的本地副本完全是最新的。
README
或
LICENSE文件。）
git push
将所有内容放回到存储库中。 （你可能需要切换到每个分支并推送它，也可能需要
git push --tags。）
FRAGILE：这种方法将丢失现有的 GitHub 问题和拉取请求评论。如果您大量使用这些，这种方法可能不是一个好主意，您应该联系 GitHub 客户支持来帮助您。
如果您可以删除（或让所有者删除）分叉 B 的原始存储库 A，那么就可以了。
如果不可能/不同意删除 A，但 A 的所有者愿意执行以下操作，则分叉链接将被破坏，至少在 GitHub Enterprise 上：
注意：如果 A 本身是从更早的历史中分叉出来的，那么不幸的是，一旦 A 消失，B 似乎就会开始默认针对该存储库打开 PR。唯一的解决方案是将上述内容应用于分叉树上游的所有存储库:(
TripIt
的存储库，因此这是他们工作的来源/父级。 事实上，如果你打开你的自己的存储库，你会看到它根本没有被分叉（分叉计数为0）。 当他们发出合并请求时，默认情况下 github 会将该存储库显示为源，因此拉取请求不会发送给您。
在这种情况下，最简单的解决方法是要求您的开发人员分叉您的存储库，并对其进行处理。
我知道的唯一解决方案
（除了删除分叉并直接从本地克隆重新创建/推送，如此处所述）是让上游所有者将原始存储库设为私有，然后将其返回到公共。将其设为私有会永久断开与分叉的链接。
但这当然需要上游所有者采取行动。 Github 确实应该解决这个问题，但这个问题已经存在很长时间了。