有关 GitHub 仓库分支的几个问题

众所周知，GitHub 通过 fork 成为一种超级存储库，让你可以看到 fork 网络中的所有提交，对私人仓库也是如此。举个例子：如果你（Bob）从 Alice 那 fork 了一个仓库 P，Alice 在你 fork 后使用散列 X 进行代码提交，你就可以通过 github.com/Bob/P/tree/X 访问这些提交。即使在你的 fork 被删除了以后，仍然可以通过任何分支访问提交，并且这些提交看起来将永远存在。

GitHub 上有人发现这其中存在以下相关问题，并联系了 GitHub。GitHub 说已经知晓了问题，可以将这些问题公开。

在被删除了访问权限后，用户仍然可以继续查看这个仓库中新的提交。这个操作的本意是想在你的访问权限被删除之前可以创建一个私有仓库。但是这样就可以让你通过哈希来访问提交。

根据 GitHub 文档，如果你删除了某人对你的私有仓库的访问权，GitHub 将删除他们的所有分支。对于你在自己账户中 fork 的仓库来说是这样的，但是对于你在组织中 fork 的仓库来说不是这样的。

场景：

• Alice 创建了一个私有仓库 p

• Alice 在 p 中添加了 Bob 的访问权

• Bob 创建了一个组织，叫 B-org

• Bob 将 p fork 进 B-org

• Alice 删除了 Bob 对 p 的访问权

• Alice 在 p 中通过哈希 X 提交了代码

• 通过访问 github.com/B-org/P/tree/X，Bob 能看到用哈希 X 提交的代码。

Bob 可以通过哈希访问 P 中的提交。一旦访问到这个提交，你也可以访问其所有的 parent，但不能访问其 children。

还有很多方法可以找到这个仓库的提交：

• 如果这个仓库的所有者有一个 GitHub Pro 账号，所有分支的哈希都会显示在 Insights -> Network。

• GitHub 允许通过 URL 中的哈希前缀引用提交，因此可以尝试暴力破解 16^4 的哈希空间（~65k），从 github.com/B-org/P/tree/0000 到 github.com / B-org / P / tree / ffff 进行迭代（也可以考虑已有的提交）。也可以通过 GitHub API 完成，但是有一个配额限制。

• 如果在 GitHub 注释中输入哈希值的 6 位前缀，GitHub 将自动链接到提交。目前找不到尺寸限制，似乎可以在一条注释中打包超过几千个哈希。请注意，GitHub 提到了反对滥用配额。

请注意，这也适用于组织和团队中的私人仓库，尤其组织需要允许用户 fork 他们的仓库。

经常关注一下自己仓库的 fork 数。如果有 GitHub Pro 的账户，可以在 Insights -> Network 标签下看到用户名。

如果你 Fork 了一个私有仓库，并从该 fork 中删除了这个仓库所有者的访问权限，你是希望所有者无法查看你的提交的。但是，他们仍然可以从他们的仓库中查找提交的哈希并创建链接来访问你的提交（像前面提到的一样）。

免费组织对私人仓库的数量有限制，免费用户在私人仓库中可以添加的协作者数量有限制。但是，如果免费用户将私人仓库 fork 到组织中，该组织将拥有一个新的私人仓库，那么该组织可以添加他们想要的所有协作者。

https://gist.github.com/sarazasasa/9450d63f96e7ff799824fc98fc7f3b43

点个好看少个bug