我对Bitbucket，GitHub和Launchpad等源代码托管设施如何实际管理主存储库中的分叉过程，以及当这些存储库分叉时如何设置保存服务器磁盘空间感到有点好奇在服务器端。
例如，如果我从GitHub上的存储库派生：我的存储库中复制的代码是否会从GitHub服务器上的主存储器中占用额外的磁盘空间（我的意思是它会导致存储重复性）？
提前致谢。
答案 0 :(得分：1)
这是一个很好的问题，让我想知道同样的事情。
幸运的是，我们可以看一下名为gitlab的开源git repo管理工具。
在gitlab-shell中，managedObjectContext函数处理分叉。检查传递的params是否有效后，执行以下行：
viewContext因此GitLab只是克隆了存储库，复制了源代码。
答案 1 :(得分：1)
基于this answer，看来Github至少在分叉时不会复制存储库。相反，它会创建前面带有用户名的新分支（例如，而不是master，我的分叉主分支将被引用为lightcc.master）。
这在Git如何存储文件并引用它们以及为什么能够如此有效地存储repos的背景下非常有意义。如果fork是repo的完美副本，那么所有需要完成的工作就是创建新的分支（跟踪引用）并跟踪谁有权查看它们并推送/拉出它们。如果我分叉一个仓库，但从不对它进行更改，那么我的跟踪引用可能会在上游仓库后面，但它们将始终与那些旧的提交相同（除非原始仓库执行一些非常糟糕的事情[tm]和通过对现有提交进行变基，挤压等来重写它的历史。
换句话说，在原始fork时，不需要复制原始repo，因此唯一的成本是进行新跟踪引用所需的字节数，即每个现有分支约40个字节。它甚至可能无法创建新的引用，直到你真正偏离原始的repo（或者直到你设置一个跟踪引用并将它推送到你的fork给定分支 - 所以master可能是自动的吗？）。
鉴于这些评论，看起来这就是Github的作用，因此Gitlab实际上复制回购的行为（按照0xcaff的回答）更类似于创建重复进程的Unix fork。 Github以非常敏捷的方式想要等到最后一刻创建任何新对象，因为fork实际上与原始repo不同。
这可能是为什么Github有一些关于将fork与原始repo完全分开的规则，以及为什么需要支持。这样做会花费他们的存储空间，如果他们让所有人都可以轻松免费地这样做，那么随着时间的推移，它可能会花费很多存储空间等。