嵌入式开发之路

Git Internals - Git内部原理大揭秘，从底层看懂Git 🧠

Properties2
description用了这么久Git，你是不是好奇：git add、git commit、git push 背后到底发生了什么？文件是怎么存储的？分支为什么切换这么快？ 本章就像“Git解剖课”，带你
tagsgit

21分钟阅读

用了这么久Git，你是不是好奇：git add、git commit、git push 背后到底发生了什么？文件是怎么存储的？分支为什么切换这么快？ 本章就像“Git解剖课”，带你钻到Git的“五脏六腑”里看一看！我们会用最简单的语言+实操代码，从底层对象、引用、打包文件讲到数据恢复，让初学者也能搞懂Git的核心原理。理解这些后，你不仅能更灵活地使用Git，遇到问题还能轻松排查，再也不会被“神秘报错”吓住～

第一部分：Git的核心对象模型

📦 Git核心对象 - 存储数据的“三大件”

Blob对象

Tree对象

Commit对象

SHA-1哈希

Git本质是一个“内容寻址文件系统”，所有数据都以“对象”形式存储，每个对象用唯一的SHA-1哈希值标识（40位字符串）。核心有三种对象，它们共同构成了Git的版本管理基础：

1. Blob对象 - 存储文件内容 📄

Blob（二进制大对象）专门存储文件的原始内容，不包含文件名、权限等元信息。可以理解为“文件内容的快照”。

1. 初始化一个空仓库，探索Blob对象 mkdir git-internal-test && cd git-internal-test git init# 2. 存储一段文本到Git数据库（生成Blob对象） # -w：写入对象到数据库；—stdin：从标准输入读取内容 echo “Hello Git Internals!” | git hash-object -w —stdin # 输出示例：7f8f296d49c33832a44e882a59d09c266a9059c2（这是Blob的SHA-1哈希） # 3. 查看Blob对象的内容 # git cat-file -p 哈希值：查看对象内容（-p=pretty print） git cat-file -p 7f8f296d49c33832a44e882a59d09c266a9059c2 # 输出：Hello Git Internals! # 4. 查看对象类型（确认是Blob） git cat-file -t 7f8f296d49c33832a44e882a59d09c266a9059c2 # 输出：blob # 5. 存储文件到Git数据库（同样生成Blob） echo “Version 1 of test.txt” > test.txt git hash-object -w test.txt # 输出示例：83baae61804e65cc73a7201a7252750c76066a30

💡 关键：相同内容的文件会生成相同的Blob对象（SHA-1相同），Git会自动去重，节省存储空间！比如两个文件内容一样，Git只存一份Blob。

2. Tree对象 - 存储目录结构 📂

Tree对象相当于“目录索引”，存储文件名、文件权限，以及对应的Blob对象哈希（或子Tree对象哈希）。可以理解为“文件夹的快照”。

1. 先创建一个暂存区（Index），添加文件到暂存区 # —add：添加文件；—cacheinfo：从Git数据库添加（而非工作区文件） # 格式：git update-index —add —cacheinfo 权限 Blob哈希 文件名 git update-index —add —cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 test.txt# 2. 从暂存区生成Tree对象（记录目录结构） git write-tree # 输出示例：d8329fc1cc938780ffdd9f94e0d364e0ea74f579（Tree的SHA-1哈希） # 3. 查看Tree对象内容（看到文件名、权限、对应的Blob哈希） git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579 # 输出：100644 blob 83baae61804e65cc73a7201a7252750c76066a30 test.txt # 100644：普通文件权限；100755：可执行文件；040000：目录（子Tree） # 4. 新增子目录，生成嵌套Tree mkdir subdir echo “Subdir file” > subdir/subfile.txt git hash-object -w subdir/subfile.txt # 生成subfile.txt的Blob git update-index —add —cacheinfo 100644 [subfile的Blob哈希] subdir/subfile.txt git write-tree # 生成包含子目录的Tree对象

类比理解

：Tree对象就像一张“文件夹清单”，上面写着“test.txt（权限644）对应Blob哈希xxx”“subdir（目录）对应Tree哈希yyy”，清晰记录了目录结构。

3. Commit对象 - 存储版本信息 📝

Commit对象是“版本的元数据容器”，记录了：当前版本的顶层Tree对象（整个项目的目录快照）、父Commit（上一个版本）、作者/提交者信息、提交时间、提交信息。

1. 基于之前的Tree对象创建Commit对象 # echo 提交信息 | git commit-tree Tree哈希 echo “First commit: add test.txt” | git commit-tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 # 输出示例：fdf4fc3344e67ab068f836878b6c4951e3b15f3d（Commit的SHA-1哈希）# 2. 查看Commit对象内容 git cat-file -p fdf4fc3344e67ab068f836878b6c4951e3b15f3d # 输出结构： # tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579（对应顶层Tree） # author Your Name your.email@example.com 1699999999 +0800（作者信息） # committer Your Name your.email@example.com 1699999999 +0800（提交者信息） # # First commit: add test.txt（提交信息） # 3. 创建第二个Commit（指定父Commit，形成版本链） # 修改test.txt，生成新的Blob和Tree echo “Version 2 of test.txt” > test.txt git hash-object -w test.txt # 新Blob哈希 git update-index test.txt # 更新暂存区 new_tree=(git write-tree) # 新Tree哈希 # 创建Commit时用 -p 指定父Commit哈希 echo "Second commit: update test.txt to version 2" | git commit-tree new_tree -p fdf4fc3344e67ab068f836878b6c4951e3b15f3d

三者关系总结

Commit → Tree → Blob：一个Commit指向一个顶层Tree（项目根目录），Tree指向子Tree或Blob，最终通过Blob获取文件内容。这就是Git版本存储的核心逻辑！

💡 为什么Git切换分支快？因为每个分支的HEAD指向最新的Commit，而Commit直接关联Tree（目录结构）和Blob（文件内容），不需要重新复制文件，只需切换指针即可！

第二部分：Git引用 - 分支和标签的本质

📍 Git引用 - 分支和标签到底是什么？

引用（refs）

HEAD指针

分支引用

标签引用

你可能好奇：分支名（如master）、标签名（如v1.0）为什么能直接对应到某个版本？答案是“引用”——引用就是一个“指针文件”，存储着Commit的SHA-1哈希，让你不用记复杂的哈希值，用简单的名字就能访问版本。

1. 分支引用 - 可移动的指针 🔄

分支本质是一个“可移动的引用”，永远指向该分支的最新Commit。当你提交新代码时，分支引用会自动移动到新的Commit。

1. 查看Git的引用目录（所有指针都存在这里） ls .git/refs # 输出：heads tags remotes（heads=分支，tags=标签，remotes=远程分支）# 2. 手动创建一个分支引用（模拟git branch命令） # 格式：echo “Commit哈希” > .git/refs/heads/分支名 echo “fdf4fc3344e67ab068f836878b6c4951e3b15f3d” > .git/refs/heads/my-branch # 3. 现在可以用分支名访问Commit git log my-branch —oneline # 输出：fdf4fc3 First commit: add test.txt # 4. 用git update-ref创建分支（更安全的方式，避免手动编辑文件） git update-ref refs/heads/another-branch [第二个Commit的哈希] # 5. 切换分支（本质是修改HEAD指针） git checkout my-branch # 查看HEAD指向：cat .git/HEAD # 输出：ref: refs/heads/my-branch

⚠️ 注意：不要手动编辑引用文件！用git branch、git checkout等命令操作，避免指针错误导致版本丢失。

2. HEAD指针 - 当前版本的“风向标” 🧭

HEAD是一个“特殊引用”，指向你当前正在工作的分支（或直接指向某个Commit，即“分离头指针”状态）。Git通过HEAD知道“当前工作区对应的是哪个版本”。

1. 查看HEAD的内容（当前在my-branch分支） cat .git/HEAD # 输出：ref: refs/heads/my-branch（指向分支引用）# 2. 切换到“分离头指针”状态（直接指向Commit） git checkout fdf4fc3344e67ab068f836878b6c4951e3b15f3d cat .git/HEAD # 输出：fdf4fc3344e67ab068f836878b6c4951e3b15f3d（直接是Commit哈希） # 3. 用git symbolic-ref操作HEAD（安全修改） git symbolic-ref HEAD refs/heads/another-branch cat .git/HEAD # 输出：ref: refs/heads/another-branch

3. 标签引用 - 固定版本的“书签” 🔖

标签（tag）是“固定的引用”，指向某个特定的Commit，不会随提交移动。适合标记版本（如v1.0、v2.1）。

1. 创建轻量标签（直接指向Commit，无额外信息） git update-ref refs/tags/v1.0 fdf4fc3344e67ab068f836878b6c4951e3b15f3d# 2. 创建带注释的标签（生成Tag对象，包含标签信息、作者、日期） git tag -a v1.1 [第二个Commit的哈希] -m “Version 1.1 with test.txt updated” # 3. 查看标签对应的Commit git show v1.0 # 输出：显示v1.0指向的Commit信息 # 4. 查看Tag对象（带注释标签会生成Tag对象） git cat-file -t [标签的哈希] # 输出：tag git cat-file -p [标签的哈希] # 输出：包含标签名、标签者、日期、标签信息、指向的Commit哈希

💡 区别：轻量标签=直接指向Commit的引用；带注释标签=生成Tag对象（存储标签元信息），引用指向Tag对象，Tag对象再指向Commit。

第三部分：Git打包文件 - 优化存储

📦 Git打包文件 - 如何高效存储大量版本？

松散对象

打包文件（packfile）

git gc

增量存储

1. 松散对象 vs 打包文件

之前生成的Blob、Tree、Commit对象都是“松散对象”（每个对象一个文件，存储在.git/objects/哈希前两位/哈希后38位）。当松散对象过多时，Git会自动（或手动）将它们打包成“打包文件（packfile）”，采用增量存储优化空间。

1. 查看当前的松散对象（之前创建的Blob、Tree、Commit） find .git/objects -type f # 输出示例： # .git/objects/7f/8f296d49c33832a44e882a59d09c266a9059c2（Blob） # .git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579（Tree） # .git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d（Commit）# 2. 手动触发Git垃圾回收（生成打包文件） git gc # 输出：Counting objects: XXX, done. Compressing objects: 100% (XXX/XXX), done. … # 3. 查看打包文件（.git/objects/pack目录下） ls .git/objects/pack # 输出：pack-xxx.idx pack-xxx.pack（idx=索引文件，pack=数据文件） # 4. 查看打包文件中的对象（验证对象被打包） git verify-pack -v .git/objects/pack/pack-xxx.idx # 输出包含所有打包的对象（Blob、Tree、Commit）及其大小

2. 增量存储 - 打包文件的核心优化

打包文件的关键优化：对于内容相似的文件，Git只存储“增量差异”（即后一个版本相对于前一个版本的变化），而不是完整内容，极大节省空间。

示例

：test.txt从“Version 1”修改为“Version 2”，打包后Git不会存储两个完整的Blob，而是存储“Version 1”的完整内容 + “Version 2”相对于“Version 1”的差异（仅修改了“1”→“2”）。

💡 什么时候Git自动打包？当松散对象超过7000个，或打包文件超过50个时，Git会自动运行git gc（垃圾回收）生成打包文件。

3. git gc 命令 - 手动优化仓库

git gc（garbage collect，垃圾回收）的作用：

  • 将松散对象打包成打包文件，节省空间
  • 合并多个打包文件为一个，提高效率
  • 删除不可达的“悬空对象”（如未被任何Commit引用的Blob）

常用git gc命令 git gc # 普通垃圾回收 git gc —auto # 自动判断是否需要回收（Git内部常用） git gc —prune=now # 立即删除过期的悬空对象（默认保留2周）

第四部分：数据恢复与仓库维护

🔧 数据恢复与仓库维护 - 救回丢失的版本

引用日志（reflog）

悬空对象

git fsck

git prune

删除大文件

1. 引用日志（reflog）- 恢复误删的分支/Commit 🕰️

Git会记录HEAD和分支的每一次移动（如提交、切换分支、重置），存储在“引用日志”中。即使误删分支或hard reset丢失Commit，也能通过reflog找回。

1. 模拟误操作：hard reset到旧版本，丢失最新Commit # 假设当前有两个Commit，HEAD在第二个Commit git log —oneline # 查看Commit：abc123（新）、fdf4fc3（旧） git reset —hard fdf4fc3 # 强制重置到旧版本，丢失abc123# 2. 查看引用日志，找到丢失的Commit git reflog # 显示HEAD的所有移动记录 # 输出示例： # fdf4fc3 (HEAD -> my-branch) HEAD@{0}: reset: moving to fdf4fc3 # abc123 HEAD@{1}: commit: Second commit: update test.txt to version 2（丢失的Commit） # 3. 恢复丢失的Commit（创建分支指向它） git branch recover-lost abc123 git checkout recover-lost # 现在找回了丢失的版本！ # 4. 详细查看reflog对应的Commit信息 git log -g # 等同于git log —reflog，显示reflog的Commit详情

⚠️ 注意：reflog是本地的！仅记录你本地的操作，不会同步到远程仓库。默认保留90天，过期会自动清理。

2. 悬空对象与git fsck - 查找丢失的对象 🔍

“悬空对象”是指没有被任何Commit、Tree或引用指向的对象（如未提交的Blob、误删分支后的Commit）。git fsck（file system check）可以检查仓库完整性，找到悬空对象。

1. 生成一个悬空Blob（存储内容但不添加到暂存区/Commit） echo “Dangling blob content” | git hash-object -w —stdin # 输出：xyz789（Blob哈希）# 2. 查找悬空对象 git fsck —full # 输出示例： # dangling blob xyz789（悬空Blob） # dangling commit abc123（如果之前的丢失Commit未被恢复） # 3. 恢复悬空Commit（创建分支指向它） git branch recover-dangling abc123

3. 删除仓库中的大文件（彻底清理）🗑️

如果不小心提交了大文件（如2GB的安装包），即使后来删除，Git历史中仍会保留该文件，导致仓库体积过大。需要彻底删除大文件的所有历史引用。

1. 找到大文件的Blob哈希（假设大文件是largefile.zip） # 查看所有Blob的大小，排序后找最大的 git rev-list —objects —all | git cat-file —batch-check=’%(objecttype) %(objectname) %(objectsize) %(rest)’ | grep ‘^blob’ | sort -k3 -n -r | head -5 # 输出示例：blob 123456 2097152000 largefile.zip（2GB大文件）# 2. 用filter-branch删除大文件的所有历史引用 # —index-filter：操作暂存区；—cached：从暂存区删除；—ignore-unmatch：忽略不存在的文件 git filter-branch —index-filter ‘git rm —cached —ignore-unmatch largefile.zip’ — —all # 3. 删除旧的引用和悬空对象 rm -rf .git/refs/original/ # 删除filter-branch生成的原始引用 git reflog expire —expire=now —all # 过期所有reflog git gc —prune=now # 垃圾回收，删除悬空对象 # 4. 验证大文件已删除（仓库体积变小） git count-objects -v # 查看仓库大小 # 输出：size-pack: XXX（单位KB，明显变小）

⚠️ 警告：此操作会修改所有Commit的SHA-1，仅适用于本地仓库或未共享的仓库！如果已推送到远程，需要强制推送（git push -f），且通知团队成员重新克隆，否则会导致冲突。

第五部分：Git传输协议 - 数据如何在本地和远程之间传输？

🌐 Git传输协议 - 本地与远程的“数据桥梁”

dumb协议

smart协议

HTTP(S)传输

SSH传输

packfile传输

1. 两种核心传输协议

Git传输数据（clone、fetch、push）时主要使用两种协议，各有适用场景：

（1）Dumb协议 - 简单的“静态文件传输” 📤

基于HTTP(S)，服务器端无需运行Git进程，只需提供.git目录下的文件（如松散对象、打包文件），客户端通过HTTP GET请求下载。优点：简单易配置；缺点：仅支持读操作（clone、fetch），不支持push，效率低。 适用场景：搭建只读的公共仓库（如开源项目的镜像），无需复杂配置。

（2）Smart协议 - 智能的“双向传输” 🤖

Git专用协议，支持读写（push、fetch），服务器端运行Git进程（如git-receive-pack、git-upload-pack），会先协商双方的对象差异，只传输需要的对象（打包成packfile），效率高。 适用场景：日常开发（clone、fetch、push），支持双向交互，是目前最常用的协议。

💡 常见传输方式对应的协议：SSH（默认用smart协议）、HTTP(S)（支持smart协议，需服务器配置）、git://（专用smart协议，无认证）。

2. 传输流程简化（以git clone为例）

  1. 客户端连接远程服务器（如SSH、HTTP），发送“获取仓库信息”请求
  2. 服务器返回仓库的引用（分支、标签对应的Commit哈希）和能力（如支持packfile、增量传输）
  3. 客户端对比本地已有的对象（首次clone则无），告诉服务器“需要哪些对象”
  4. 服务器将需要的对象打包成packfile（增量优化），发送给客户端
  5. 客户端接收packfile，解压并存储到本地.git/objects目录，完成克隆

查看Git传输的详细日志（调试用） GIT_TRACE_PACKET=true git clone https://github.com/git/git.git # 输出传输过程中的数据包交互，可看到协商、打包、传输的细节

总结与交付物提议

🎯 本章总结 - Git内部原理核心要点

  • 核心对象：Blob（文件内容）、Tree（目录结构）、Commit（版本元数据），通过SHA-1哈希唯一标识，构成Git的版本存储基础
  • 引用系统：分支、标签、HEAD都是“指针”，指向Commit或对象，让用户无需记忆复杂哈希
  • 存储优化：松散对象→打包文件（git gc），增量存储相似文件，极大节省空间
  • 数据恢复：reflog记录HEAD移动，git fsck查找悬空对象，可找回误删的分支和Commit
  • 传输协议：smart协议为主，协商差异后传输packfile，高效支持双向交互

要不要我帮你整理一份Git内部原理速查手册？包含核心对象操作、引用管理、数据恢复、仓库优化的常用命令和原理图解，让你遇到底层问题时能快速查阅，彻底吃透Git的工作机制～

关系图谱