Git如何既节省空间又快速？

我刚在学校看了第一个教程

Git如何存储所有文件的所有版本，以及它如何比只保存最新版本的代码更节省空间

我知道这可以通过压缩来实现，但这是以速度为代价的，但这也说明Git的速度要快得多（尽管它获得最大收益的是它的大多数操作都是离线的）

我猜是这样的

• Git广泛压缩数据
• 它仍然更快，因为

  解压缩+工作

  仍然比

  网络获取+工作

---

我说得对吗？即使很接近？

也不是一个完整的答案，但是（来自）可能会对问题的空间管理方面有所帮助：

这里有几件事值得澄清

首先，Git存储库可能比SVN存储库更大；我希望我没有暗示那从来都不是事实。然而，在实践中，通常情况下，Git存储库比同等的SVN存储库占用更少的磁盘空间。
您提到的一件事是Apache的单一SVN存储库，它显然非常庞大。但是，只需查看

git.apache.org

，您就会注意到每个apache项目都有自己的git存储库真正需要的是同类之间的比较；换句话说，（abdera）SVN项目的签出与（abdera）Git存储库的克隆相比

我可以签出

git://git.apache.org/abdera.git

。在磁盘上，它消耗了28.8Mb。
然后我检查了SVN版本

http://svn.apache.org/repos/asf/abdera/java/trunk/

，它消耗了34.3Mb。
这两个数字都是从RAM空间中单独装入的分区中获取的，引用的数字是从磁盘获取的字节数。
如果使用

du-sh

作为测试手段，Git校验是11Mb，SVN校验是17Mb

ApacheAbdera的Git版本可以让我处理当前版本之前的任何历史版本；SVN将只有当前签出版本的备份。但它占用的磁盘空间更少

你可能会问，怎么做？

嗯，首先，SVN创建了更多的文件。SVN签出有2959个文件；相应的Git存储库有845个文件

其次，虽然SVN在层次结构的每个级别都有一个

.SVN

文件夹，但Git repo在顶层只有一个

.Git

存储库。这意味着（除其他外）从一个dir重命名到另一个dir在Git中的影响相对较小，而在SVN中的影响则相对较小

第三，Git将其数据存储为压缩对象，而SVN将其存储为未压缩副本。进入任何

.svn/text base

目录，您将找到（base）文件的未压缩副本。
Git有一种机制，可以将所有文件（实际上是所有历史记录）压缩到包文件中。在Abdera的例子中，

.git/objects/pack/

在一个4.8Mb的文件中有一个.pack文件（包含所有历史记录）。
因此，在本例中，存储库的大小（大致）与当前签出代码的大小相同，尽管我不希望总是这样

不管怎样，你是对的，历史记录可以增长到超过当前签出的总大小；但是由于SVN的工作方式，它必须接近两倍的大小才能产生很大的不同。即使如此，磁盘空间的减少也不是使用DVCS的主要原因；当然，这在某些方面是一种优势，但这并不是人们使用它的真正原因

请注意，Git（和Hg以及其他DVCSs）确实存在这样一个问题：签入（大型）二进制文件，然后将其删除，因为它们仍然会显示在存储库中并占用空间，即使它们不是最新的。文本压缩处理文本文件的这类事情，但二进制文件更为重要。（有一些管理命令可以更新Git存储库的内容，但它们的开销/管理成本略高于CVS；Git筛选器分支类似于

svnadmin dump/filter/load

）

---

至于速度方面，我在我的“回答”中提到了这一点（比如：（在这里解释）“任何涉及网络的事情都会扼杀性能”）

所提到的是一个很好的补充，即使它不直接处理Subversion。
它确实列出了您需要在DVCS性能方面监控的操作类型

---

本文还提到了其他Git基准测试。

我想您会问，Git克隆（完整存储库+签出）如何可能比Subversion中签出的源更小。或者你是说别的什么

这个问题在评论中得到了回答

---

存储库大小 首先，您应该考虑到Subversion在那些

.svn

子目录中存储原始副本（最新版本）。原始副本以未压缩的方式存储在Subversion中

其次，git使用以下技术缩小存储库：

• 文件的每个版本只存储一次；这意味着，如果在10次修订（10次提交）中只有某个文件的两个不同版本，git只存储这两个版本，而不是10个版本
• 对象（和三角洲，见下文）被压缩存储；编程中使用的文本文件压缩效果非常好（约为原始大小的60%，或压缩后大小减小40%）
• 重新打包后，对象以deltified形式存储，这与其他版本不同；此外，git尝试以这样一种方式对增量链进行排序，即增量主要由