Github fork的解释以及它们如何存储文件

Question

我只是想知道在github上完成fork时会发生什么.

例如,当我分叉一个项目时,它是否在github服务器上复制了所有代码,或者只创建了一个链接？

所以另一个问题:在git中,因为如果你向它添加相同的文件它会散列所有文件,它不需要再次存储文件内容,因为散列已经在系统中了,对吗？

github是这样的吗？因此,如果我碰巧上传与另一个用户完全相同的代码片段,那么当github gits时它实际上只是创建一个指向该文件的链接,因为它具有相同的哈希值,或者它是否单独再次保存所有内容？

任何启示都会很棒,谢谢!

Answer 1

github.com与git的语义完全相同,但基于Web的GUI界面也是如此.

存储:"Git将文件的每个版本存储为唯一的blob对象"
因此每个文件都是唯一存储的,但它使用SHA-1哈希来确定文件之间的更改.

至于github,fork本质上是一个克隆.这意味着新的fork是其服务器上的一个新存储区域,并引用了它的ORIGIN.它绝不会在两者之间建立联系,因为git本质上可以跟踪遥控器.每个分支都知道上游.

当你说"如果我碰巧上传与另一个用户完全相同的代码"时,术语"上传"在"git"意义上有点模糊.如果您正在使用相同的存储库,并且git甚至允许您提交相同的文件,这意味着它是不同的并且它在该修订中签入.但是,如果你的意思是在另一个repo的克隆/ fork上工作,那将是相同的情况,但也不会在文件系统上与其他repo建立链接.

我不能声称对内部系统内部github可能做出的优化有任何了解.他们可能正在进行中间自定义操作以节省磁盘空间.但是他们所做的任何事情对你来说都是透明的,并且无关紧要,因为它应该总是在预期的git语义下运行.

github的开发人员写了一篇关于他们如何在内部执行自己的git工作流的博客文章.虽然它与您关于如何管理服务的实际工作流程的问题无关,但我认为结论的引用非常有用:

Git本身的理解起来相当复杂,使得你使用它的工作流程比必要的更复杂,只会给每个人的日子增加更多的心理开销.我总是提倡使用最简单的系统,这个系统将适用于您的团队并且这样做,直到它不再起作用,然后仅在绝对需要时添加复杂性.

我从中得到的是,他们承认复杂的git本身是多么复杂,所以他们最有可能采取最轻微的触摸来包裹它以提供服务,让git做本来最好的事情.

Answer 2

根据https://enterprise.github.com/releases/2.2.0/notes GitHub Enterprise（我假设 GitHub）以某种方式在分叉之间共享对象以减少磁盘空间使用：

此版本更改了 GitHub Enterprise 存储仓库的方式，通过在复刻之间共享 Git 对象来减少磁盘使用，并提高读取仓库数据时的缓存性能。

在https://githubengineering.com/counting-objects上还有更多关于他们如何做的细节。