尽管 GIT 不存储文件增量，但您仍然可以回滚到以前的文件版本（无限次？）

Question

我读过Git 不存储文件增量。如果是这样，它如何支持文件回滚到以前的版本？如果它存储整个文件，磁盘上的存储库空间必须增长到无法管理的大。Git 是否支持文件回滚和 diff(s) 回文件版本 1？它甚至支持与文件相关的版本控制概念吗？这（我相信）对于我理解 VCS/DVCS 和我的需求至关重要。我需要能够将我将要签入的内容与以前的版本进行比较。

Answer 1

Git 不会自行丢弃信息*。每个文件的所有先前版本始终可用于还原、差异、检查等。

全树与单个文件

您可能想要协调的是访问单个文件的旧版本的想法与 Git 的历史模型专注于整个树的事实。全树版本控制确实需要更多的工作来查看（例如）十次更改前与十次全树更改前foo.c存在的版本foo.c：

# 10 foo.c-changes ago
git show $(git rev-list -n 10 --reverse HEAD -- foo.c | head -1):foo.c

# 10 whole-tree-changes ago
git show HEAD~10:foo.c

面向树的好处，主要是能够将提交视为对整个树的各个部分进行的相互依赖更改的单元，通常大大超过额外的输入（可以通过别名、脚本等来缓解）和 CPU 时间花在挖掘过去的提交上。

存储效率

当一个新对象（例如一个包含以前未见内容的文件）进入系统时，它会以普通 (zlib) 压缩方式存储为“松散对象”。当积累了足够多的松散对象时（基于gc.auto配置选项；或者当用户运行git gc或较低级别的打包命令之一时），Git 会将许多松散对象收集到一个“打包文件”中。

包文件中的对象可以存储为纯压缩数据（与松散对象相同，只是与其他对象捆绑在一起）或作为针对其他对象的压缩增量存储。Delta 可以链接到可配置的深度 ( pack.depth) 并且可以针对任何合适的对象制作（pack.window控制 Git 搜索最佳 delta 基础的范围；如果这样做会产生良好的效果，可以使用与历史无关的文件的版本作为基础）增量压缩）。深度和窗口大小配置为 delta 压缩引擎提供的宽容度通常会导致比 CVS 风格的简单版本对下一个/上一个版本的“差异”压缩更好的 delta 压缩。

正是这种积极的增量压缩（与普通的 zlib 压缩相结合）通常可以让 Git 存储库（具有完整的历史记录和未压缩的工作树）比单个 SVN 签出（具有未压缩的工作树和原始副本）占用更少的空间。

请参阅The Git Community Book的How Git Stores Objects和The Packfile部分。还有git pack-objects联机帮助页。

_{* 您可以通过“重写历史记录”和git reset 之类的命令告诉 Git 丢弃提交，但即使在这些情况下，Git 也会“挂起”新丢弃的提交一段时间，以防万一您决定需要它们。请参阅git reflog和git prune。}

Answer 2

可以在同一页上阅读：

...

因此，Git 不会在源代码树以下的任何级别显式记录文件修订关系。

...

检查单个文件的更改历史记录比检查整个项目的更改历史记录要稍微昂贵一些。要获取影响给定文件的更改历史记录，Git 必须遍历全局历史记录，然后确定每个更改是否修改了该文件。然而，这种检查历史记录的方法确实可以让 Git 以同等效率生成单个历史记录，显示对任意文件集的更改。例如，源树的子目录加上关联的全局头文件是非常常见的情况。

...

因此，您可以返回到文件的先前修订版本并比较两个文件。