Git .git 目录内部结构与 reflog 灾难恢复实战

摘要：Git 的 .git 目录是版本控制的核心引擎，理解其内部结构是解决合并冲突混乱、误删分支、错误回退等灾难场景的前提。本文拆解 .git/objects、.git/refs、.git/HEAD 的存储机制，并详解 git reflog 在恢复误操作提交、找回 git reset --hard 后丢失代码、恢复已删除分支等场景中的实战用法。

一、为什么需要理解 .git 目录

竞品的 Git 教程几乎全部从 git init 跳到 git add 和 git commit，中间从来不解释这些命令到底在 .git 目录里写了什么。这种黑盒式的学习路线在日常操作时没太大问题，但一旦遇到以下场景就会陷入被动：

• 执行 git reset --hard HEAD~3 后发现删错了，但 git log 已经看不到被丢弃的提交
• 用 git branch -D feature-x 强制删了一个分支，之后发现还有代码没合并
• 合并冲突处理到一半想放弃，但不知道如何干净回退
• 仓库突然变得很臃肿，想知道哪些对象占用了大量空间

这些问题如果只停留在 add/commit/push 层面是解决不了的。需要理解 .git 目录的内部结构。

二、.git 目录核心结构拆解

进入任意一个 Git 仓库，执行 tree .git -L 1 可以看到如下结构：

.git/
├── HEAD
├── config
├── objects/
├── refs/
├── index
├── logs/
├── hooks/
└── info/

2.1 HEAD —— 当前指向

HEAD 文件只记录一行文本，指向当前检出的引用：

$ cat .git/HEAD
ref: refs/heads/main

它的含义是：当前工作在 main 分支上。当你执行 git checkout feature-x 时，HEAD 的内容会变成 ref: refs/heads/feature-x。如果执行 git checkout <commit-hash> 进入 detached HEAD 状态，HEAD 会直接记录一个 40 位的 SHA-1 哈希值。

实践中这个文件的作用：如果在 git rebase 过程中遇到冲突，想直接放弃并回到 rebase 之前的状态，可以执行：

$ git rebase --abort

这个命令就是通过读取 ORIG_HEAD 和 rebase-merge 目录中的状态信息来恢复的。理解 HEAD 机制后，遇到 rebase 卡住时就不会盲目关终端重来。

2.2 objects/ —— 所有数据存储的地方

objects 目录是 Git 存储所有内容的仓库，存放方式按 SHA-1 哈希值的前两位划分子目录。Git 内部有四种对象类型：

查看某个 commit 的内部结构：

$ git cat-file -p HEAD
tree 4b825dc642cb6eb9a060e54... # 指向项目根目录的 tree 对象
parent a1b2c3d4e5f6...           # 上次提交
author dev <dev@example.com> 1768848000 +0800
committer dev <dev@example.com> 1768848000 +0800

fix: 修复登录页样式问题

理解这一点对后续的灾难恢复至关重要：Git 删除分支并不会立即删除其指向的 commit 对象。只要 commit 对象还在 objects 目录中，就能通过 reflog 恢复。

三、git reflog —— 30 天的安全网

git reflog 是 Git 内置的引用日志，记录了 HEAD 和分支指针的每一次移动。默认保留 30 天（可配置 gc.reflogExpire）。

查看当前分支的 reflog：

$ git reflog
a1b2c3d HEAD@{0}: commit: 修复登录页样式问题
e4f5g6h HEAD@{1}: reset: moving to HEAD~2
i7j8k9l HEAD@{2}: commit: 添加用户模块
m0n1o2p HEAD@{3}: commit (initial): 初始化项目

reflog 与 git log 的关键区别：

• git log 只显示当前可达的提交链（从 HEAD 出发能追溯到的提交）
• git reflog 记录了 HEAD 的每一次位置变化，包括已被 git reset --hard 丢弃的提交

这是恢复误操作的基础：即使 git log 里看不到了，reflog 里仍然有记录。

四、实战：三个典型灾难恢复场景

场景 1：git reset --hard 后恢复丢失的提交

$ git reset --hard HEAD~3           # 手滑多回退了两次
$ git log                            # 最新的两个提交消失了
commit m0n1o2p                        # 只剩最初的提交

恢复方法：

$ git reflog                        # 找到 reset 前 HEAD 的位置
i7j8k9l HEAD@{3}: commit: 添加用户模块
e4f5g6h HEAD@{4}: commit: 添加订单模块

$ git reset --hard HEAD@{3}          # 回到 reset 之前的状态
$ git log --oneline                  # 提交已恢复
i7j8k9l 添加用户模块
e4f5g6h 添加订单模块
m0n1o2p 初始化项目

场景 2：恢复被误删的分支

$ git branch -D feature-payment     # 误删了分支
$ git reflog --all                   # 查看所有引用的日志
...
a1b2c3d refs/heads/feature-payment@{1}: commit: 完成支付接口

恢复方法：

$ git checkout -b feature-payment a1b2c3d
# 或
$ git branch feature-payment a1b2c3d

只要 reflog 未过期（默认 30 天），分支上的 commit 能找回来。Git 的垃圾回收（git gc）只有在对象不可达且 reflog 过期后才会真正删除数据。

场景 3：合并冲突想放弃，但不知道如何干净回退

$ git merge feature-x
CONFLICT (content): 在 index.html 中合并冲突

此时 HEAD 处于合并中间状态。如果决定放弃本次合并：

$ git merge --abort

但如果已经手动编辑了冲突文件并运行了 git add，--abort 将不再可用：

$ git reset --merge

这条命令将索引和工作区恢复到合并前的状态。它的原理是通过 reflog 读取 MERGE_HEAD 的指向位置。

五、reflog 的维护与清理

reflog 不是无限增长的。Git 默认配置下，可达对象的 reflog 保留 90 天，不可达对象保留 30 天。查看当前配置：

$ git config --get gc.reflogExpire
$ git config --get gc.reflogExpireUnreachable

如果磁盘空间紧张，可以手动触发垃圾回收并清理过期 reflog：

$ git reflog expire --expire=now --all
$ git gc --prune=now

但这个操作不可逆——执行后所有 reflog 记录将被清除，通过 reflog 恢复的操作不再可能。在生产环境中执行前务必确认不需要恢复任何历史。