很多开发者每天都在用 Git 提交代码，却很少有人真正理解 Git 内部原理：为什么一次提交能瞬间回滚？为什么误删的分支往往还能找回？答案藏在 Git 的对象模型里。Git 本质上是一个内容寻址的文件系统，所有数据都以对象形式存储，并用 SHA-1 哈希作为唯一地址。本文带你用底层命令亲手重建一次提交，并掌握基于对象模型与引用日志的数据恢复实战。
一、Git 是内容寻址文件系统
与 SVN 这类”按文件名记录差异”的系统不同，Git 把每一次内容都当作不可变的对象存进 .git/objects 目录，文件名就是内容的 SHA-1 哈希。这种设计带来三个直接好处：内容去重（相同内容只占一份空间）、完整性校验（哈希不匹配立即报错）、以及天然的”数据可恢复”——只要对象还在，它就永远不会凭空消失。
执行 git init 后，.git 目录会出现几个关键子目录：objects（存储所有对象）、refs（存储引用，即分支与标签指针）、HEAD（指向当前所在引用）。理解这三者的关系，就理解了 Git 90% 的行为。
二、三种核心对象：blob、tree、commit
2.1 blob 与 tree
blob（二进制大对象）只保存文件内容，不含文件名；tree 则记录”文件名 → blob/tree 哈希”的映射，相当于目录。一个 tree 可以嵌套另一个 tree，从而表达完整的目录结构。注意：改变文件内容会生成新的 blob，改变文件名则会生成新的 tree，但旧对象依然保留。
2.2 commit 对象
commit 对象指向一个根 tree，并包含作者、提交者、提交说明，以及父提交的哈希（首次提交没有父）。正是这个”父指针”串起了提交链，让 Git 能够沿历史回溯。下面的实战会让你亲眼看到这些对象是如何拼起来的。
三、动手观察：用底层命令重建一次提交
Git 提供了一组”管道命令”（plumbing），它们不假设你有工作区，而是直接操作对象。我们抛开 git add 和 git commit，一步步手动构造对象：
# 1. 把文件内容写入对象库，返回 blob 的 SHA-1
echo "hello git" > readme.txt
git hash-object -w readme.txt
# 输出类似：3b18e512dba79e4c8300dd08aeb37f8e728b8dad
# 2. 查看任意对象的类型与内容
git cat-file -t 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
# blob
git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
# hello git
接下来我们手动构造 tree 和 commit，体会引用是如何层层指上去的：
# 3. 用当前索引生成一个 tree 对象
git update-index --add readme.txt
git write-tree
# 输出 tree 的 SHA-1，例如：d8329fc1cc938780ffdd9f94e0d364e0ea74f579
# 4. 基于这个 tree 创建 commit 对象（无父，首次提交）
echo "first commit" | git commit-tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
# 输出 commit 的 SHA-1
# 5. 把分支指针指向这个 commit
git update-ref refs/heads/main <commit-sha>
git checkout main
你会发现，git checkout main 之后看到的内容，和你用高层命令提交的结果完全一致。这套机制说明：分支不过是一个指向 commit 的轻量指针，重命名或删除分支并不会删除背后的 commit 对象。
四、引用（ref）与 HEAD 的工作方式
打开 .git/HEAD，你会看到它并不直接存哈希，而是一行 ref: refs/heads/main。Git 解析引用时遵循”间接寻址”：HEAD 指向分支，分支指向 commit。这样切换分支只是改 HEAD 的目标，成本极低。
# 查看 HEAD 与分支当前指向
cat .git/HEAD
# ref: refs/heads/main
cat .git/refs/heads/main
# 一串 commit 的 SHA-1
五、为什么 Git 不会轻易丢数据：内容寻址 + 引用日志
Git 的”安全感”来自两层保护。第一层是内容寻址：对象一旦写入就不可变，任何操作都是”新增对象”而非”覆盖旧对象”。第二层是 reflog（引用日志），它记录了 HEAD 和分支指针每一次移动的历史，默认保留 90 天。即便你 reset --hard 把分支指回旧提交，reflog 里依然留着”消失的那个 commit 去哪了”。
# 查看 HEAD 的引用日志
git reflog
# 每条记录形如：
# a1b2c3d HEAD@{0}: reset: moving to HEAD~1
# e4f5g6h HEAD@{1}: commit: add feature x
六、实战：误删分支与提交如何恢复
6.1 场景一：git reset –hard 之后
这是最让人心慌的操作——所有未提交的改动似乎”瞬间蒸发”。但只要那个 commit 曾被创建过，它就在对象库里。先用 git reflog 找到 reset 之前的哈希，再创建一个新分支指向它即可：
# 找到 reset 之前那条的哈希（如 e4f5g6h）
git reflog
git checkout -b recover e4f5g6h
# 现在 recover 分支完整还原了当时状态
git checkout main
git merge recover # 确认无误后合并回主分支
6.2 场景二：误删分支
用 git branch -D 删除分支后，分支指针没了，但 commit 对象还在，只是变成了”悬空对象”（dangling）。用 git fsck 可以扫出所有不可达对象，再按 reflog 或时间找回：
# 找出所有悬空 commit
git fsck --lost-found
# 输出 dangling commit e4f5g6h...
# 直接基于悬空 commit 复活分支
git branch rescued e4f5g6h
git checkout rescued
这里的关键认知是：Git 的删除几乎都是”删指针”而非”删数据”。真正清理对象要等到 git gc 触发且对象已不可达并超过过期时间，在此之前你都有充足时间挽救。
七、dangling 对象与垃圾回收
悬空对象是那些没有任何引用（分支、标签、reflog）指向的对象。Git 会定期执行 git gc 压缩对象并清理过期悬空对象。如果你想主动查看哪些对象即将被回收，可以用：
# 列出不可达对象
git fsck --unreachable
# 手动触发一次垃圾回收（默认仍保留 2 周内的对象）
git gc --prune=now
经验法则：在真正执行 git gc --prune=now 之前，任何误删都能救回；执行之后，悬空对象被物理删除，就只能依赖外部备份了。
八、常见误区与排错
| 误区 / 现象 | 真相 | 正确处理 |
|---|---|---|
| reset –hard 后改动没了 | commit 仍在 reflog 里 | git reflog 找哈希，checkout -b 复活 |
| branch -D 删了分支 | commit 变 dangling 未删 | git fsck –lost-found 找回 |
| stash 后找不到 | stash 也是 ref，在 reflog | git stash list / git stash pop |
| 想永久删除某段历史 | 普通删除无效，对象仍留 | git filter-repo + gc –prune=now |
九、和工具链协作：把原理用起来
理解对象模型后，你会发现很多工具的设计都建立在此之上。例如 GitHub Actions 流水线本质上是把仓库的某个 commit 拉到干净环境执行；Trivy 镜像扫描与 SonarQube 静态分析常作为提交门禁，在 commit 进入主干前拦下问题；而 Docker Compose 编排与 VS Code 插件则让本地复现提交环境变得轻而易举。掌握底层，才能在上层工具出错时快速定位是”环境”还是”数据”问题。
十、落地清单
| 动作 | 命令 | 目的 |
|---|---|---|
| 观察对象 | git cat-file -p <hash> | 看清 blob/tree/commit 结构 |
| 查看引用日志 | git reflog | 找回任意历史指针位置 |
| 扫描悬空对象 | git fsck –lost-found | 定位被删分支的数据 |
| 复活分支 | git branch name <hash> | 基于旧 commit 重建引用 |
| 谨慎清理 | git gc –prune=now | 确认无误后再物理删除 |
把 Git 内部原理装进肌肉记忆，你就不会再害怕 reset --hard 或误删分支。记住一句话：在 Git 里，删除几乎总是删除指针，而不是删除数据——只要对象模型还在，数据恢复就永远有路可走。
