我的问题比标题中声明的问题更笼统。
我知道源版本控制仅存储有关差异的信息。据我了解，维基百科也是如此，github也是如此。
但是它们都能够显示具有特定修订版的整个文件。他们是否以增量方式将其从第一个修订版还原到特定修订版？
还有一个问题。如果它们仅存储差异，则它们如何在具有上下文的 UI 中显示它们（更改前后的少量文本）。
编辑：github存储整个快照而不是增量
我知道源版本控制仅存储有关差异的信息。
正如 Git 设计决策关于存储内容而不是差异的问题所说明的那样，这并不完全是 Git 所做的。
不过，它确实具有"打包"格式，使用LibXDiff库中的二进制增量以增量形式存储对象。但这主要用于网络传输。
请参阅"git 二进制差异算法（增量存储）是否标准化？
这就是为什么 git 在获取时"解析增量"的原因。
有关存储版本控制数据的不同方式的优缺点的非常有趣的阅读，我强烈建议阅读Eric Sink的文章版本控制存储中的时间和空间权衡。
存储是版本控制最困难的挑战之一 系统。 对于每个文件，我们必须存储曾经拥有的每个版本 存在。 版本控制存储库的逻辑大小从不 收缩。 它只是不断增长和增长，每个旧版本 需要保持可用。
那么，存储所有内容的每个版本的最佳方法是什么？
基百科，可悲的是...将数据库中的每个修订都以某种形式的 XML（？） 作为文本保存。
看看维基百科数据库模式。特别是最近的更改和文本。
因此，他们对"生物学"页面的第一个副本有很好的O（1）查找。这有一个不幸的副作用，导致维基百科的技术成本从2010-2011年的800万美元膨胀到2011-2012年的1200万美元。尽管HDD（和其他所有东西）变得越来越便宜，而不是更贵。
保留每个文件的修订控制就这么多。Git 采用了一种可爱的方法。请参阅 git 存储模型是否浪费？。
它存储每个文件，类似于上述方法。一旦存储库占用的空间超过某个限制，它就会进行暴力重新打包（有一个选项可以设置它的尝试强度 - --window=[N]， --depth=[N]），这可能需要几个小时。它使用增量和无损压缩的组合进行所述重新打包（递归增量，然后在您拥有的任何位上无损应用）。
其他像SVN这样的使用简单的增量压缩。（来自内存，你不应该相信）。
脚注：增量压缩存储增量更改。无损压缩很像zip，RAR等。