git lfs 是否会减少推送到 Github 的文件的大小？

Question

Github 不允许推送大于 100 MB 的文件。使用git lfs，可以将大文件推送到 Github。我只是对这个过程的想法感到好奇：在我看来，这git lfs只是一个额外的开关，可以将大文件（仅通过 https://）推送到 Github。但我无法想象，仅此而已？

阿尔特拉西亚国家的文献

Git LFS（大文件存储）是由 Atlassian、GitHub 和其他一些开源贡献者开发的 Git 扩展，它通过延迟下载大文件的相关版本来减少存储库中大文件的影响。具体来说，大文件是在签出过程中而不是在克隆或获取过程中下载的。Git LFS 通过用小指针文件替换存储库中的大文件来实现此目的。在正常使用期间，您永远不会看到这些指针文件，因为它们是由 Git LFS 自动处理的。

---

一些细节：我有一个小项目，由于一个大文件，我无法将其推送到 github。然后我可以按如下方式迁移和推送：

git lfs migrate import --everything --include="*.pdf"
git reflog expire --expire-unreachable=now --all
git gc --prune=now
git push origin master
git lfs checkout (? If you have local files with 1 kB only? Happend some days later...)

所有内容都被推送到 Github - 即使是大文件。那么，如果允许使用git lfs（可以快速安装并且易于使用），为什么Github拒绝大文件呢？

Answer 1

问题不在于大文件本身，而在于 Git 存储它们的方式。Git 使用增量和压缩来存储文件并通过网络发送文件。增量化通过引用另一个文件并仅存储差异来存储数据较少的文件。

当服务器端重新打包存储的数据时，Git 也会通过运行来验证数据是否仍然完好无损git fsck。这意味着每个文件都必须至少部分地被解压缩、反增量化并处理到内存中。对于大文件，这会导致使用大量的 CPU 和内存，从而影响服务器上存储的其他存储库。文件也可能被重新删除，这意味着该文件和其他文件必须完全读入内存，以一定的成本与其他文件进行比较，然后重写和重新压缩。另一种方法是简单地存储这些文件而不进行增量化并仅压缩它们，但这会导致磁盘使用失控，尤其是对于压缩效果不佳的文件。

在客户端，用户必须下载克隆上的整个存储库。这导致使用大量带宽来克隆大文件，而这些文件通常是不可压缩的，并且意味着用户必须在本地存储所有这些内容，即使他们只对一些修订感兴趣。

Git LFS 通过使用单独的基于 HTTP 的协议并允许将对象上传到不属于主 Git 存储库的单独位置，消除了 Git 存储库中的所有存储。这意味着可以避免 Git 为压缩和增量而产生的成本，并且用户只能下载当前结帐所需的文件。这意味着服务器负载和带宽以及客户端存储需求都大大减少。