Git 使用哈希节约空间

Blob 的算盘

我们知道，git 保存文件内容的方式，是将内容压缩并写入一个 blob 对象，而 blob 对象对应的路径，是对文件内容求哈希得到的。

比如，我们有一个内容为 a 的文件，git 对 a 取哈希后得到 78981922613b2afb6025042ff6bd878ac1994e85。Git 通过这个哈希值来确定保存 blob 对象的地址，即 .git/objects/78/981922613b2afb6025042ff6bd878ac1994e85。

这样有一个什么好处呢？相同的内容会生成同一个 blob 对象，并写入同一个 blob 对应文件。也就是说，如果我们有文件 letter1.txt 和文件 letter2.txt，它们有相同的内容，那么这两个文件会共享同一个 blob 对象，这样对 blob 来说就节省了一半的磁盘空间。

醒一醒？

“这样对 blob 来说就节省了一半的磁盘空间”。哈哈，太天真了。如果仓库中同时存在多个内容相同的文件，这个项目也该被弃掉了。

的确，这种相同文件内容的场景是很少的。但是，需要注意的是，git 是一个版本管理系统，它追踪的是一整个文件变更的历史。如果 letter1.txt 的内容在 100 个提交中都没有发生变化，那么我们就节约了 99 份 letter1.txt 对应的 blob 对象占用的磁盘空间。

但是这并不能说明 git 有多高明，我们只能设想如果 git 不这么做会有多傻。

更大的 blob

Blob 可以共享，很大程度上依赖一个事实，那就是 blob 对象内是不包含时间相关的信息的。

Git 还在更大的单位上实现了共享