“Git提交是快照而非差异”是否会导致存储需求增大？

你完全没误解“提交是快照”这个核心概念，但Git Book确实没把底层存储的优化逻辑说透——它说的“快照”是提交层面的逻辑模型，而实际存储时Git会自动做空间压缩，不会让你的仓库因为大文件修改就直接膨胀。

针对你说的4GB dictionary.txt文件的例子，实际情况是这样的：

• 第一次提交时，Git会生成对应这个4GB文件的Blob对象（会先做zlib压缩，实际占用空间比4GB小）。
• 当你添加一行再提交时，Git不会直接生成一个新的4GB+一行的Blob。反而会通过delta压缩技术，只存储新内容和原Blob的差异部分——这个差异是Git基于内容寻址自动计算的，不需要你手动处理。
• 更关键的是Git的packfile机制：当仓库积累了一定数量的松散对象（比如多次修改后的Blob），Git会自动触发git gc（垃圾回收），把相关对象打包成一个单独的packfile文件，里面用delta链式存储多个版本的文件——比如原4GB文件作为基础，后续修改只存差异，整体体积会小很多。

再明确两个层面的区别：

• 提交模型层面：每个提交确实是仓库的完整快照，你可以随时切换到任意提交，看到当时所有文件的状态，这是Git和其他VCS最核心的差异。
• 底层存储层面：Git会自动对重复或相似内容做压缩、delta存储，不会每次都存完整大文件。Git Book强调前者是因为这是入门阶段必须理解的核心逻辑，后者属于内部实现细节，没在基础章节展开。

你可以自己做个测试验证：创建一个大文件，提交后修改一小部分再提交，然后用git count-objects -vH查看仓库实际占用空间，会发现远小于两个大文件的体积之和。

内容的提问来源于stack exchange，提问作者Izzo