多数 Git 事故的起点通常早于 merge conflict，常落在对仓库保存方式的误读里。

团队每天使用 branch、pull request、force-push，谈到 Git 时却容易把它当成一个托管协作产品，命令行只是附带入口。官方文档给出的图景更具体：Git 保存 snapshot，用 refs 给 object 命名，再依靠内容寻址校验完整性。[1][2][3] 这一层看清以后，许多日常混乱会自然收束。

真正值得带走的判断很朴素：仓库承诺保留什么，哪些对象随后会被垃圾回收纳入候选，以及这两种状态之间的分界为什么落在 reachability 上。[2][3][6]

1. 对象才是仓库本体，工作区只是其中一种视图

Git 的核心数据由少数 object 类型组成：blob、tree、commit 与 annotated tag。[2] blob 保存文件内容，tree 保存目录以及 mode/name/object 的链接关系，commit 保存元数据、顶层 tree 指针，通常还保存一个或多个父提交。[2]

Git 的主身份因此落在 snapshot 和 object graph 上。官方 "What is Git?" 章节把 Git 描述为面向快照的系统，internals 章节进一步说明原因：commit 以顶层 tree 锚定整个项目状态，读取历史时顺着 tree 展开，省去了反复重跑 patch script 的过程。[1][2]

这件事在工程里很有用，因为它解释了 Git 为什么能仅凭 object identity 恢复那么多上下文。只要 object graph 仍然完整，历史、目录状态、文件内容之间的关系仍然可以重新展开。仓库首先是 object database，branch tip 和其他带名字的入口把这套数据库带到日常操作面前。[2][3]

2. Branch 本质上是 ref，提交历史借此获得名字

接下来最值得纠正的一点，是 branch 容易被误看成“装着 commits 的文件夹”。Branch 实际是 ref：一个名字，值通常是某条开发线末端 commit 的 object ID。[3] ref 移动，屏幕上看到的 branch tip 也跟着移动；commits 本身仍留在原来的关系里。

gitrepository-layout 文档把这一点写得更具体。refs 常见地保存在 .git/refs/ 下，较少更新或较旧的 refs 会为了效率被收进 packed-refs。[4] HEAD 通常是一个 symbolic ref，指向当前 branch tip，充当当前工作位置的命名入口。[3][4]

放到这一层看，rebase 与 force-push 的语义会清楚得多。所谓 history rewrite，实际是在生成或复用 commits，然后把 refs 重新指向另一组 commit IDs。[3] 风险也随之出现：旧 object 一旦脱离 refs 的承托，就失去维持 reachability 的主要路径之一。[6]

3. Loose objects 负责工作中的增量写入，packfiles 让长期仓库保持经济

如果所有数据单元都长期以 loose object 形式存在，Git 的存储成本会过高。Packfiles 章节给出的答案是：Git 可以把大量 object 打进 packfile，并借助 delta 关系降低存储与传输成本。[5]

这会同时改变两件事。

第一，日常开发仍然足够轻。新 object 可以先以 loose object 的方式逐步写入，不用在每次操作时都承担完整 repack 的代价。[2][5] 第二，长期仓库仍然便于传输。条目数量很高时，clone 与 fetch 之所以还能维持可接受的成本，packfiles 是关键原因之一。[5]

这里最容易被忽略的地方，是把 packfiles 当成没有行为后果的底层细节。它们不会改写 Git 判断身份的方式，却解释了大型仓库或长期运行仓库为什么需要 git gc 与 repack 这类维护动作。[5][6] 存储形态和历史形态始终互相牵连。

4. 真正的持久化合同落在 reachability

Git 最强的安全性质来自一句话：这个 object 仍然能从 Git 会保护的根节点到达。[6]

git gc 文档明确说明，垃圾回收会尽力保留那些仍被 branches、tags、index、remote-tracking branches、reflogs 以及仓库内其他 object references 指向的 object。[6] 这句话就是最重要的运行合同。数据仍连在这些受保护根之下时，持久性就有明确支撑；这些连接消失之后，再叠加时间老化条件，相关 object 才会进入 prune 候选。[6]

许多“提交明明丢了又被找回”的经历，都可以用这层逻辑解释。某次 reset 或 rebase 之后从 branch 上消失的 commit，常会因为另一个 ref 或 reflog 还指向它而被恢复。真正无人命名、无人可达的 object，只是在借时间生存。Git 的态度很保守，但它没有承诺永久保存 unreachable objects。[6]

工程实践里，refs 承担治理功能，也承担日常操作的标签功能。一次高风险 rewrite 之前先打一个 lightweight tag，做历史整理前先分出一条临时 branch，或者在本地清理之前先把一个 remote ref 发出去，这些动作都在显式延长 reachability。[3][6] 理解这点的团队，面对历史改写时往往更从容，因为他们知道自己究竟在保护哪条安全线。

5. 这会如何改变日常工程习惯

接受 object + reachability 这套视角以后，许多习惯就更容易站稳：

1. 做破坏性历史操作前先创建 branch 或 tag，因为名字就是保留根节点的方式。[3][6]
2. 把 reflog 恢复视作本地安全网，因为 reflog 只属于本仓库，也有时间范围。[6]
3. 把 force-push 理解成 ref 移动，再把协作成本单独纳入评估。[3][6]
4. 把托管平台工作流与 Git 仓库原理拆开看；pull requests 位于 Git 的存储模型之上，围绕 refs 与 commits 组织协作界面。[1][2][3]

最后一点对平台团队尤其重要。许多关于工作流的争论，本质上是在讨论应当给 refs 与 commits 叠加什么 policy。Git 本身比围绕它建立起来的协作层更小，也更严格。

结语

Git 长期保持强大，靠的是一组很收敛的核心：content-addressed objects、带名字的 refs、高效的 packfiles，以及依 reachability 运转的垃圾回收。[2][3][5][6] 这四部分一旦连起来看，很多在界面层看起来危险的仓库操作都会重新变得可解释。

日常收益也很具体。它意味着更少的意外历史丢失，更平静的 rewrite 流程，以及更准确的判断：仓库里的哪些名字只是为了方便，哪些名字正在真实地为数据续命。

来源

1. Git SCM，《What is Git?》—— Git 的快照模型、完整性设计重点与高层目标。
2. Git SCM，《Git Internals: Git Objects》—— blob、tree、commit、tag 的对象结构与对象数据库模型。
3. Git SCM，《Git Internals: Git References》—— branch refs、tags、HEAD 与对象图中的命名入口。
4. Git SCM，《gitrepository-layout》—— refs、objects 与 packed-refs 在仓库中的位置。
5. Git SCM，《Git Internals: Packfiles》—— 对象打包、delta 压缩与仓库规模化后的效率来源。
6. Git SCM，《git gc》—— 垃圾回收行为、受保护根节点与 unreachable objects 的裁剪边界。