【Git 内部原理】`.git` 是怎么记住所有版本的

​ 每次git commitGit 都说已记录。但你有没有想过改了几十次、几百次Git 是怎么全记住的难道每次提交它都复制一份完整项目​ 这篇文章不讲命令也不背概念。 我们直接打开.git文件夹看 Git到底存了什么。读完你会明白三件事为什么 Git 几乎不会变慢为什么分支创建几乎是瞬间完成为什么 Git 能精确还原任何历史版本一、.git文件夹里有什么​ 当你执行git init项目根目录会多出一个.git文件夹。这个文件夹就是 Git 的全部家当。如果删掉它相当于告诉 Git“我从来没有版本历史。”​ 如果只看关键部分结构大致如下.git/ ├── objects/ ← 所有版本数据都存在这里 ├── refs/ ← 分支和标签的指针 ├── HEAD ← 当前在哪个分支 └── config ← 仓库配置比如 remote 地址你可以在任意 Git 仓库里自己看一眼tree .git-L1​ 会列出.git下的所有一级目录和文件和上面的结构一一对应。1.1objects/所有版本数据的仓库最重要的目录Git 记住所有版本的秘密全在这里。​ 这是.git里最核心的目录。你提交过的每一份文件内容、每一次目录结构、每一个 commit全都以对象的形式存在这里。后面几节会详细讲 Git 是怎么组织这些对象的。​ 你可以进去看看ls.git/objects/​ 会看到一堆两位字母的文件夹如3a、f2这些是对象哈希值的前两位Git 用它来分散存储避免单个目录下文件太多。1.2refs/分支和标签的指针​refs/里存的是引用本质上就是一个个小文件。​ 可以看到每个文件里只写了一行 commit 哈希值。cat.git/refs/heads/main 9cf71a0e00a25a56c416113ce1a66c6c247aa2bf​ 这就是main分支的指针它指向这个分支最新的一次 commit。你每次提交Git 就把这个文件里的哈希值更新成新的 commit。​ 标签也类似存在refs/tags/下。1.3HEAD你现在在哪​HEAD是一个特殊的文件记录当前工作在哪个分支上cat.git/HEAD ref: refs/heads/main​ 意思是我现在在 main 分支。如果你git checkout到某个具体的 commit而不是分支HEAD 会直接存那个 commit 的哈希值这就是所谓的detached HEAD状态。1.4 config仓库级别的配置​ 这个文件存的是只对当前仓库生效的 Git 配置比如远程仓库的地址cat.git/config​ 你会看到类似[remote origin]和url ...这样的内容。git remote add其实就是在往这个文件里写东西。​ 它和全局的~/.gitconfig是分开的。仓库级配置优先级更高会覆盖全局配置中的同名选项。二、Git 存东西的方式快照不是差异​ 很多人以为 Git 记录的是每次改了什么例如这次改了哪几行代码差异其实不是。Git 记录的是每次提交时项目的完整快照snapshot。​ 听起来很浪费别急Git 有个聪明的设计相同内容只存一份。2.1 举例​ 假如有一个项目里面有三个文件README.md app.py config.yaml两次commit第一次 commitGit 把三个文件的内容都存进objects/。第二次 commit你只改了app.py。Git 会怎么做README.md没变 →不存直接指向上次那份config.yaml没变 →不存直接指向上次那份app.py变了 →存一份新的所以虽然 Git 记录的是完整快照但没变的文件零开销只有真正改了的文件才会占空间。左边是很多版本管理工具的做法只记录每次的改动diff右边是 Git 的做法记录完整快照但没变的文件不重复存储直接指回原来那份。三、三种积木blob、tree、commit​ Git 的objects/里只有三种东西像三块积木搭起了整个版本历史。3.1blob文件内容​ 每个文件的内容会被存成一个blobBinary Large Object。注意blob 只存内容不存文件名。如果两个文件内容完全一样Git 只存一个 blob不管它们叫什么名字。3.2tree目录结构​tree 记录的是哪个文件名对应哪个 blob相当于一张目录清单README.md → blob-A app.py → blob-B config.yaml → blob-C​ 如果有子文件夹tree 里还会嵌套 tree。3.3commit一次快照​commit 把这些都串起来。一个 commit 包含指向一个 tree这次提交时项目长什么样指向父 commit上一次提交是谁作者、时间、提交信息​ commit 指向 treetree 指向 blob三层结构各司其职。commit 记录谁在什么时候提交的tree 记录项目有哪些文件blob 记录文件里写了什么。四、用一个例子串起来​ 假设你做了两次提交第二次只改了app.py。第一次 commitcommit-1 └── tree-1 ├── README.md → blob-A ├── app.py → blob-B └── config.yaml → blob-C第二次 commitcommit-2父节点 → commit-1 └── tree-2 ├── README.md → blob-A ← 同一个 blob没有重新存 ├── app.py → blob-D ← 新 blob内容变了 └── config.yaml → blob-C ← 同一个 blob进行了两次 commitobjects/里一共只有对象数量说明commit2 个每次提交一个tree2 个目录结构变了app.py 指向不同 blobblob4 个A、B、C、D其中 A 和 C 被两个 tree 共享​ 一共8 个对象。如果每次都复制一份需要 6 个 blob现在只要 4 个。文件越多、改动越少这个优势越明显。两次提交产生了两个 commit 和两个 tree但 blob-AREADME.md和 blob-Cconfig.yaml因为内容没变被两个 tree 共享这就是 Git 快照但不浪费的关键。五、项目越来越大怎么办​ 靠上面的内容去重已经省了很多空间但项目跑久了对象还是会越来越多。Git 还有两招压缩每个对象存入时会用 zlib 压缩。代码都是文本压缩率很高实际占用比原始文件小得多。打包packfile当松散对象积累太多时Git 会自动把它们打包成.git/objects/pack/下的 packfile。打包时 Git 会计算相似对象之间的增量差异只存和上一版的区别进一步压缩。你不需要手动触发这些git push和git gc时 Git 会自动处理。Git 先把每个对象单独压缩存放松散对象积累多了就自动打包成 packfile利用相似对象之间的增量差异进一步节省空间。六、动手看一看​ 前面讲了这么多概念不如自己动手验证一下。找一个有过提交记录的 Git 仓库跟着下面的步骤操作。​ 我们会用到一个底层命令git cat-file。平时用不到它但它是查看 Git 对象内容的万能工具给它一个对象的哈希值或者 HEAD 这样的引用它就能把对象的内容打印出来。6.1 Step1查看当前commit的内容# 看当前 commit 的内容gitcat-file-pHEAD​HEAD指向当前分支的最新 commit所以这条命令会打印出这个 commit 对象的内容。输出大致长这样​ 可以看到commit 里记录了一个tree 哈希值这次提交时项目的目录快照、parent上一次 commit、以及作者和提交信息。和之前介绍的完全一致。6.2 Step2查看tree​ 把上一步输出中tree后面的哈希值复制过来。-p参数的意思是pretty-print让输出更易读。gitcat-file-ptree哈希值​ 这条命令打印的是目录快照也就是提交时项目根目录下有哪些文件和子目录。输出类似​ 每一行就是一个条目文件对应 blob子目录对应另一个 tree。100644是普通文件的权限040000是目录。6.3 Step3看blob里有什么​ 再从上一步的输出中挑一个 blob 的哈希值gitcat-file-pblob哈希值​ 这里我们选择app.py对应的blob的哈希值查看对应的文件内容​ 这次输出的就是文件的原始内容一字不差。blob 就是这么简单。因为它只存内容不存文件名文件名记在 tree 里。​ 从 commit 到 tree 到 blob可以一层层追下去。commit 告诉你谁在什么时候提交了什么tree 告诉你项目有哪些文件blob 告诉你文件里写了什么。这就是 Git 存储的全貌没有其他魔法。七、总结.git/objects/是 Git 的核心仓库所有版本数据都在这里Git 记录的是完整快照但相同内容只存一份没改的文件零开销三种对象各管一件事blob 存内容、tree 存目录、commit 存快照项目再大也不怕zlib 压缩 packfile 增量打包Git 会自动管理空间下次再git commit的时候你就知道 Git 在背后做了什么了不是复制粘贴而是精打细算地存了一个快照。