一句话定义：Git 存储架构（Git Storage Architecture）指 Git「把代码历史存成什么形状、又靠什么找到它」的底层设计，包括对象怎么打包、指针怎么组织、历史怎么加速索引。
先看它存什么。 Git 不保存两个版本之间的差异，只保存一次次快照：每个文件内容算出一个哈希值，作为它的名字，这叫内容寻址（content-addressed）。四种对象撑起一切：blob（文件内容）、tree（目录结构）、commit（一次提交）、tag（标签）。零散存放的是「松散对象」，攒多了就压成 packfile（包文件），相似内容只存增量。可以把仓库看成一座货仓：货架上放的是压缩过的货箱，而 ref（引用，如 main 分支）只是贴在墙上的便签，写着「当前这批货的编号」。
小仓库里，所有便签塞进一个 packed-refs 文件就够用，谁要更新就锁整面墙。但当一个仓库有几十万分支、AI 一天生成成千上万次提交时，这面墙就成了瓶颈：改一个分支得排队等整面墙解锁。于是有了 ref 分片（ref sharding）：把总账拆成多本分册，按名字前缀分片，改哪片就锁哪片，并发写入互不打架。
commit-graph 解决「查家谱太慢」。要判断一个提交是不是另一个的祖先，传统办法是沿父提交一层层向上爬。commit-graph 是预先算好的索引文件，把父链和世代号（generation number）提前写下，查询时直接跳转，像家谱里标好「第几代」，不用每次从老祖宗数起。
部分克隆（partial clone）则是「别把整座仓库搬回家」：克隆时只取目录和提交，文件内容用到再去取。它和浅克隆（shallow clone，直接砍掉早期历史）不同：部分克隆保留完整历史，只是晚点取内容。
| 方式 | 拿到什么 | 代价 |
|---|---|---|
| 完整克隆 | 全部历史与文件 | 最慢、最占磁盘 |
| 浅克隆 | 最近若干次提交 | 历史不全，部分操作受限 |
| 部分克隆 | 全部提交，文件按需拉取 | 首次取文件需联网 |
对从业者意味着什么：日常写代码几乎感受不到这些机制，但它们决定了三件事：超大仓库能否几秒内克隆完、CI 拉代码会不会拖到十分钟、AI 批量提交时平台会不会被写锁卡住。做平台工程、CI/CD、大仓治理的人值得记住：瓶颈常常不在磁盘容量，而在「指针怎么锁、历史怎么查、内容何时取」。各家托管平台的具体实现与支持情况，以官方文档为准。