多数 Git 失误起点落在存储模型的误解里，merge conflict 往往出现在后段。

团队每天都在使用 branch、pull request、force-push，谈论 Git 时却常把它想成一个托管协作产品，命令行只是附属入口。官方文档呈现的是更严格的一层：Git 存的是 snapshot，通过 refs 给对象命名，再用内容寻址对象维持完整性。[1][2][3] 这一层一旦看清，很多日常混乱都会随之收束。

真正有用的判断很直接：仓库究竟承诺保留什么，哪些对象在后续阶段会进入垃圾回收候选，以及这两种状态之间的分界为何落在 reachability。[2][3][6]

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

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

顺着这层结构展开，Git 的主身份落在快照与对象图上。官方 "What is Git?" 章节把 Git 描述为一个面向快照的系统，internals 章节进一步说明了原因：commit 通过顶层 tree 锚定整个项目状态，历史读取围绕树结构展开。[1][2]

这条事实在工程里很重要，因为它解释了 Git 为什么能从对象身份本身恢复那么多上下文。只要对象图仍然完整，历史、目录状态与文件内容关系就仍然可以被重新展开。仓库首先是一个对象数据库，带名字的入口与 branch tip 则把这套结构变成日常可操作的界面。[2][3]

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

接下来最值得纠正的一点，是把 branch 看作 ref，也就是一个名字，而这个名字的值通常就是某条开发线末端 commit 的对象 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] 风险也随之显形：旧对象一旦失去 refs 的承托，就会失去维持 reachability 的主要路径之一。[6]

3. Loose objects 负责工作中的增量写入，packfiles 负责长期经济性

如果所有对象都长期以 loose object 形式存在，Git 的对象模型就会显得过于昂贵。Packfiles 章节给出的答案是：Git 可以把大量对象打包进 packfile，并通过 delta 关系降低存储和传输成本。[5]

这会同时改变两件事。

第一，日常开发阶段仍然足够灵活。新对象可以先以 loose object 的方式被逐步写入，不需要在每次操作时都承担完整 repack 的代价。[2][5] 第二，长期仓库仍然保持可传输性。对象数量很高时，clone 与 fetch 之所以仍能维持可接受的成本，packfiles 是核心原因之一。[5]

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

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

Git 最强的安全性质来自“这个对象仍然能从 Git 会保护的根节点到达”。[6]

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

很多“提交明明丢了又被找回”的经历，其实都可以用这层逻辑解释。某次 reset 或 rebase 之后从 branch 上消失的 commit，常会因为另一个 ref 或 reflog 还指向它而被恢复。真正无人命名、无人可达的对象，只是在借时间生存。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 长期保持强大，不靠界面层的熟悉感，而靠一套很收敛的核心：内容寻址对象、带名字的 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 的裁剪边界。