Git 提交是版本差异、快照还是修改历史？
理解Git提交实现方式对我来说很简单，但理解他人对提交的看法却有难度。因此，我在Mastodon上向他人提出了一些问题。大家是怎么看待Git提交的？我进行了一个非常不科学的调查，询问大家是怎么看待Git提交的：是快照、差异，还是所有之前提交的列表？（当然，把它看作这三者都是合理的，但我很好奇人们的主要结果是：51%差异42%快照4%所有之前的提交的历史记录3%“其他”我很惊讶差异和快照两个选项的比例如此接近。人们还提出了一些有趣但相互矛盾的观点，比如“在我看来，提交是一个差异，但我认为它实际上是以快照的形
理解Git提交实现方式对我来说很简单，但理解他人对提交的看法却有难度。因此，我在Mastodon上向他人提出了一些问题。
大家是怎么看待 Git 提交的？
我进行了一个 非常不科学的调查，询问大家是怎么看待 Git 提交的：是快照、差异，还是所有之前提交的列表？（当然，把它看作这三者都是合理的，但我很好奇人们的 主要
结果是：
- 51% 差异
- 42% 快照
- 4% 所有之前的提交的历史记录
- 3% “其他”
我很惊讶差异和快照两个选项的比例如此接近。人们还提出了一些有趣但相互矛盾的观点，比如
“在我看来，提交是一个差异，但我认为它实际上是以快照的形式实现的” 和
“在我看来，提交是一个快照，但我认为它实际上是以差异的形式实现的”。关于提交的实际实现方式，我们稍后再详谈。
在我们进一步讨论之前：我们的说 “一个差异” 或 “一个快照” 都是什么意思？
什么是差异？
我说的“差异”可能相当明显：差异就是你在运行 git show COMMIT_ID 时得到的东西。例如，这是一个 rbspy 项目中的拼写错误修复：
diff --git a/src/ui/summary.rs b/src/ui/summary.rs
index 5c4ff9c..3ce9b3b 100644
--- a/src/ui/summary.rs
+++ b/src/ui/summary.rs
@@ -160,7 +160,7 @@ mod tests {
";
let mut buf: Vec = Vec::new();
-stats.write(&mut buf).expect("Callgrind write failed");
+stats.write(&mut buf).expect("summary write failed");
let actual = String::from_utf8(buf).expect("summary output not utf8");
assert_eq!(actual, expected, "Unexpected summary output");
}
你可以在 GitHub 上看到它： https://github.com/rbspy/rbspy/commit/24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b
什么是快照？
我说的 “快照” 是指 “当你运行 git checkout COMMIT_ID 时得到的所有文件”。
Git 通常将提交的文件列表称为 “树”（如“目录树”），你可以在 GitHub 上看到上述提交的所有文件：
https://github.com/rbspy/rbspy/tree/24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b（它是 /tree/ 而不是 /commit/）
“Git 是如何实现的”真的是正确的解释方式吗？
我最常听到的关于学习 Git 的建议大概是 “只要学会 Git 在内部是如何表示事物的，一切都会变得清晰明了”。我显然非常喜欢这种观点（如果你花了一些时间阅读这个博客，你就会知道我 喜欢
但是作为一个学习 Git 的方法，它并没有我希望的那么成功！通常我会兴奋地开始解释 “好的，所以 Git
提交是一个快照，它有一个指向它的父提交的指针，然后一个分支是一个指向提交的指针，然后……”，但是我试图帮助的人会告诉我，他们并没有真正发现这个解释有多有用，他们仍然不明白。所以我一直在考虑其他方案。
但是让我们还是先谈谈内部实现吧。
Git 是如何在内部表示提交的 —— 快照
在内部，Git 将提交表示为快照（它存储每个文件当前版本的 “树”）。我在 在一个 Git 仓库中，你的文件在哪里？ 中写过这个，但下面是一个非常快速的内部格式概述。
这是一个提交的表示方式：
$ git cat-file -p 24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b tree e197a79bef523842c91ee06fa19a51446975ec35 parent 26707359cdf0c2db66eb1216bf7ff00eac782f65 author Adam Jensen1672104452 -0500 committer Adam Jensen1672104890 -0500 Fix typo in expectation message
以及，当我们查看这个树对象时，我们会看到这个提交中仓库根目录下每个文件/子目录的列表：
$ git cat-file -p e197a79bef523842c91ee06fa19a51446975ec35 040000 tree 2fcc102acd27df8f24ddc3867b6756ac554b33ef.cargo 040000 tree 7714769e97c483edb052ea14e7500735c04713eb.github 100644 blob ebb410eb8266a8d6fbde8a9ffaf5db54a5fc979a.gitignore 100644 blob fa1edfb73ce93054fe32d4eb35a5c4bee68c5bf5ARCHITECTURE.md 100644 blob 9c1883ee31f4fa8b6546a7226754cfc84ada5726CODE_OF_CONDUCT.md 100644 blob 9fac1017cb65883554f821914fac3fb713008a34CONTRIBUTORS.md 100644 blob b009175dbcbc186fb8066344c0e899c3104f43e5Cargo.lock 100644 blob 94b87cd2940697288e4f18530c5933f3110b405bCargo.toml
这意味着检出一个 Git 提交总是很快的：对 Git 来说，检出昨天的提交和检出 100 万个提交之前的提交一样容易。Git 永远不需要重新应用 10000 个差异来确定当前状态，因为提交根本就不是以差异的形式存储的。
快照使用 packfile 进行压缩
我刚刚提到了 Git 提交是一个快照，但是，当有人说 “在我看来，提交是一个快照，但我认为它在实现上是一个差异”
时，这其实也是对的！Git
提交并不是以你可能习惯的差异的形式表示的（它们不是以与上一个提交的差异的形式存储在磁盘上的），但基本的直觉是，如果你要对一个 10,000
行的文件编辑 500 次，那么存储 500 份文件的效率会很低。
Git 有一个将文件以差异的形式存储的方法。这被称为 “packfile”，Git 会定期进行垃圾回收，将你的数据压缩成 packfile 以节省磁盘空间。当你 git clone 一个仓库时，Git 也会压缩数据。
这里，我没有足够的篇幅来完整地解释 packfile 是如何工作的（Aditya Mukerjee 的 《解压 Git packfile》是我最喜欢的解释它们是如何工作的文章）。不过，我可以在这里简单总结一下我对 deltas 工作原理的理解，以及它们与 diff 的区别：
- 对象存储为 “原始文件” 和一个 “变化量delta” 的引用
- 变化量是一系列例如 “读取第 0 到 100 字节，然后插入字节 ‘hello there’，然后读取第 120 到 200 字节” 的指令。它从原始文件中拼凑出新的文本。所以没有 “删除” 的概念，只有复制和添加。
- 我认为变化量的层次较少：我不知道如何检查 Git 究竟要经过多少层变化量才能得到一个给定的对象，但我的印象是通常不会很多。可能少于 10 层？不过，我很想知道如何才能真正查出来。
- 原始文件不一定来自上一个提交，它可以是任何东西。也许它甚至可以来自一个更晚的提交？我不确定。
- 没有一个 “正确的” 算法来计算变化量，Git 只是有一些近似的启发式算法
当你查看差异时，实际上发生了一些奇怪的事情
当我们运行 git show SOME_COMMIT 来查看某个提交的差异时，实际上发生的事情有点反直觉。我的理解是：
所以，Git 会将变化量转换为快照，然后计算差异。它感觉有点奇怪，因为它从一个类似差异的东西开始，最终得到另一个类似差异的东西，但是变化量和差异实际上是完全不同的，所以这是说得通的。
也就是说，我认为 Git 将提交存储为快照，而 packfile 只是一个实现细节，目的是节省磁盘空间并加快克隆速度。我其实从来没必要知道 packfile 是如何工作的，但它确实能帮助我理解 Git 是如何在不占用太多磁盘空间的情况下将提交快照化的。
一个 “错误的” Git 理解：提交是差异
我认为一个相当常见的，对 Git 的 “错误” 的理解是：
- 提交是以基于上一个提交的差异的形式存储的（加上指向父提交的指针和作者和消息）。
- 要获取提交的当前状态，Git 需要从头开始重新应用所有之前的提交。
这个理解当然是错误的（在现实中，提交是以快照的形式存储的，差异是从这些快照计算出来的），但是对我来说它似乎非常有用而且有意义！在考虑合并提交时会有一点奇怪，但是或许我们可以说这只是基于合并提交的第一个父提交的差异。
我认为这个错误的理解有的时候非常有用，而且对于日常 Git 使用来说它似乎并没有什么问题。我真的很喜欢它将我们最常使用的东西（差异）作为最基本的元素——它对我来说非常直观。
我也一直在思考一些其他有用但 “错误” 的 Git 理解，比如：
- 提交信息可以被编辑（实际上不能，你只是复制了一个相同的提交然后给了它一个新的信息，旧的提交仍然存在）
- 提交可以被移动到一个不同的基础上（类似地，它们是被复制了）
我认为有一系列非常有意义的、 “错误” 的对 Git 的理解，它们在很大程度上都受到 Git 用户界面的支持，并且在大多数情况下都不会产生什么问题。但是当你想要撤销一个更改或者出现问题时，它可能会变得混乱。
将提交视为差异的一些优势
就算我知道在 Git 中提交是快照，我可能大部分时间也都将它们视为差异，因为：
- 大多时候我都在关注我正在做的 更改 —— 如果我只是改变了一行代码，显然我主要是在考虑那一行代码而不是整个代码库的当前状态
- 点击 GitHub 上的 Git 提交或者使用
git show时，你会看到差异，所以这只是我习惯看到的东西 - 我经常使用变基，它就是关于重新应用差异的
将提交视为快照的一些优势
但是我有时也会将提交视为快照，因为：
- Git 经常对文件的移动感到困惑：有时我移动了一个文件并编辑了它，Git 无法识别它是否被移动过，而是显示为
“删除了 old.py，添加了 new.py”。这是因为 Git 只存储快照，所以当它显示 “移动 old.py -> new.py”
时，只是猜测，因为 old.py 和 new.py 的内容相似。 - 这种方式更容易理解
git checkout COMMIT_ID在做什么（重新应用 10000 个提交的想法让我感到很有压力） - 合并提交在我看来更像是快照，因为合并的提交实际上可以是任何东西（它只是一个新的快照！）。它帮助我理解为什么在解决合并冲突时可以进行任意更改，以及为什么在解决冲突时要小心。
其他一些关于提交的理解
Mastodon 的一些回复中还提到了：
- 有关提交的 “额外的” 带外信息，比如电子邮件、GitHub 拉取请求或者你和同事的对话
- 将“差异”视为一个“之前的状态 + 之后的状态”
- 以及，当然，很多人根据情况的不同以不同的方式看待提交
人们在谈论提交时使用的其他一些词可能不那么含糊：
- “修订”（似乎更像是快照）
- “补丁”（看起来更像是差异）
就到这里吧！
我很难了解人们对 Git 有哪些不同的理解。尤其棘手的是，尽管 “错误” 的理解往往非常有用，但人们却非常热衷于警惕 “错误”
的心智模式，所以人们不愿意分享他们 “错误” 的想法，生怕有什么 Git 解释者会站出来向他们解释为什么他们是错的。（这些 Git
解释者通常是出于善意的，但是无论如何它都会产生一种负面影响）
但是我学到了很多！我仍然不完全清楚该如何谈论提交，但是我们最终会弄清楚的。
感谢 Marco Rogers、Marie Flanagan 以及 Mastodon 上的所有人和我讨论 Git 提交。
Postman是一套面向API全生命周期的开发与测试平台，可在Mac上发送和调试多种协议请求，管理集合、环境及认证信息，并完成脚本测试、模拟服务、监控、文档发布和团队协作。它适合开发、测试及运维人员使用，提供个人免费方案。
Docker Desktop 是 Docker 官方为 Mac 提供的容器开发环境，集成 Docker Engine、命令行工具、Compose、Build、Kubernetes 与图形化管理界面。
Android Studio 是 Google 面向安卓应用开发提供的官方集成开发环境，基于 IntelliJ IDEA 构建。它整合智能代码编辑、Gradle 构建、界面预览、设备模拟、性能分析、调试测试及 APK 分析等工具。
Xcode 是苹果面向 Mac 提供的官方集成开发环境，将代码编辑、项目构建、SwiftUI 实时预览、设备模拟、自动化测试、断点调试、性能分析和应用分发整合在同一套工作流中，适合开发与维护 iPhone、iPad、Mac、Apple Wa
JetBrains WebStorm 是面向 JavaScript、TypeScript 和现代 Web 技术的专业集成开发环境，可智能理解项目结构，提供代码补全、重构、错误检查、运行调试、测试及 Git 工具。
PhpStorm 是 JetBrains 推出的专业 PHP 集成开发环境，可在 Mac 上完成代码编写、智能检查、重构、调试、测试和数据库管理。它支持主流 PHP 框架、Composer、Git、Docker 与远程解释器。
JetBrains PyCharm 是面向 Python 开发者的集成开发环境，提供智能补全、代码检查、重构、调试、测试、版本控制及虚拟环境管理功能。Mac 版兼容 Intel 与 Apple 芯片，核心功能可免费使用。
IntelliJ IDEA 是 JetBrains 推出的专业集成开发环境，重点服务于 Java、Kotlin 与 JVM 项目开发。软件集成代码补全、静态检查、重构、调试、测试、版本控制及构建工具，并可借助插件扩展语言和框架支持。
Visual Studio Code 是微软提供的免费代码编辑器，支持 macOS，并为 Intel 与 Apple 芯片 Mac 提供适配版本。软件集代码编辑、调试、Git 源代码管理、集成终端和扩展市场于一体。
REAPER是Cockos开发的数字音频工作站，提供多轨音频与MIDI录制、剪辑、处理、混音和母带制作工具。Mac版兼容Intel与Apple芯片，支持AU、VST、VST3、CLAP等插件格式，并提供高度可定制的工作流程。
Adobe Audition 是面向播客、影视后期、音乐制作及内容创作者的专业音频工作站，提供波形精修、多轨录制与混音、频谱编辑、降噪修复、响度匹配和效果处理工具，并可与 Adobe Premiere 协同完成视频声音制作。
Pro Tools 是 Avid 推出的专业数字音频工作站，覆盖多轨录音、无损剪辑、MIDI 编曲、插件处理、自动化混音及声音与画面同步等工作。它拥有 Intro、Artist、Studio 和 Ultimate 等方案。
PixPix 是面向品牌、卖家和内容团队的在线 AI 图片视频创作平台，提供图视频 Agent、无限画布、图片生成、视频生成、自然语言编辑及商品套图、产品精修和带货视频等电商工具。
Postman 是面向 API 全生命周期的开发与协作平台。Windows 桌面版可用于构建和发送 HTTP、GraphQL、gRPC、WebSocket、MQTT 等请求，并提供环境变量、集合、脚本测试、模拟服务、监控、文档及团队工作区等
Docker Desktop 为 Windows 开发者提供集成式容器环境，内置 Docker Engine、命令行工具、Compose、Build 与 Kubernetes 等组件，可在本机完成镜像构建、容器运行、日志查看和资源管理。
Android Studio 是 Google 面向 Android 应用开发提供的官方集成开发环境，以 IntelliJ IDEA 为基础，集成智能代码编辑、Gradle 构建、设备模拟、界面预览、调试测试及性能分析工具，
WebStorm 是 JetBrains 面向 JavaScript、TypeScript 和现代 Web 技术打造的集成开发环境。它提供项目级代码分析、智能补全、安全重构、导航搜索，并集成调试、测试、终端、Git 与常用前端工具，
PhpStorm 是 JetBrains 面向 PHP 与现代 Web 开发打造的专业集成开发环境，提供代码补全、静态检查、重构、调试、测试、数据库、版本控制及前端语言支持。Windows 用户可直接下载安装程序，
PyCharm 是 JetBrains 推出的 Python 集成开发环境，提供智能代码补全、错误检查、重构、调试、测试、Git、终端及 Jupyter Notebook 支持。统一版安装后可体验 30 天 Pro 功能，
JetBrains IntelliJ IDEA 是以 Java、Kotlin 和 JVM 项目为核心的专业集成开发环境，提供智能补全、代码检查、安全重构、调试、测试、版本控制及构建工具集成。统一发行版的核心功能可免费用于商业和非商业项目，
Visual Studio Code 是微软推出的免费代码编辑器，Windows 版集成智能补全、代码导航、调试、终端和版本控制，并可通过扩展添加语言、格式化及远程开发能力。它启动较快、配置灵活，
REAPER 是 Cockos 推出的数字音频工作站，适用于录音、MIDI 编曲、音频编辑、混音、母带制作及声音设计。软件安装包小巧，支持多轨录制、灵活路由、自动化、第三方插件和脚本扩展，并提供完整功能的 60 天免费评估期。
Adobe Audition 是面向播客、影视后期、广播与音乐制作的专业音频工作站，提供波形编辑、多轨混音、频谱分析、录音、降噪修复和效果处理等功能。Windows 版通过 Adobe Creative Cloud 安装和管理，
Pro Tools 是 Avid 推出的专业数字音频工作站，提供多轨录音、音频剪辑、MIDI编曲、插件处理、自动化混音及影视声音制作能力。它适合音乐人、录音师、制作人和音频后期团队使用，并提供免费入门版、订阅方案及永久授权选择。