先说结论,git使用了Delta增量压缩算法,git-lfs实测没有进行任何压缩,这个结论让我很震惊。
测试过程如下:
测试git仓库自身的压缩
准备一个包含许多杂项文件的文件夹,大概几百M,要保证有一个txt文本文件,做修改用,我们就叫这个文件夹为[数据包]。
将[数据包]压缩为TestFile.zip,我这里压缩结果大小为115M,然后放进本地仓库里。
步骤1、将TestFile.zip进行add、commit然后push到远程仓库:

步骤2、对[数据包]中的一个txt文件稍做修改,依旧是压缩为TestFile.zip,然后替换掉本地git仓库的同名文件,从而模拟修改,再次执行步骤1。
将步骤1、2这一过程循环执行3遍,这样的话,就意味着有三个115M大小的文件被push到远程仓库中,我们来验证一下远程中央仓库大小:

如上所示,远程仓库的大小确实是3*115=345M,也就是说,无论你连续几次提交之间的差异有多小,在提交并推送时,远程仓库并不会[立即]进行Delta压缩。
我们再看一下咱们的本地仓库大小:

本地仓库显示459M,实际也是合理的,因为本地仓库是[工作空间]+[仓库]:

文章比较了git的Delta增量压缩技术与git-lfs在处理大文件修改时的空间效率。git在多次小修改间能有效压缩,而git-lfs即使文件只有微小差异也会完整存储,不进行压缩。结论是git-lfs不适合频繁修改大文件的场景。
最低0.47元/天 解锁文章
7万+

被折叠的 条评论
为什么被折叠?



