新手阶段看git log屏幕上那串commit 5f2c4a1...是什么我从来没细想过。直到有一次我改了提交信息发现整个哈希变了又有一次reset之后工作区消失翻了半天发现提交还在再后来看别人的文章提到“Git存的是快照不是差异”我才意识到真正理解Git的第一个关卡就是搞懂提交对象commit object。它不是Git的边角料而是整个版本历史的发动机。这篇文章我就把这台发动机拆开从内部结构、存储格式到手搓一个提交对象再到amend、rebase、误删恢复、.git泄露这些实战问题全部串起来讲一遍。适合刚学会git add、git commit但总被各种诡异行为搞懵的初学者也适合准备面试、想真正吃透Git底层原理的人。1. 提交对象到底是什么1.1 一次git commitGit在背后都干了什么我最早在Windows上用Git 2.23每天机械地敲git add .、git commit -m ...完全不知道这些命令背后经历了什么。后来为了弄清楚我在一个空目录里反复做实验才把这件事还原出来。一次完整的git commitGit至少做了四件事第一git add把工作区文件转成blob对象。Git会读取文件内容计算哈希把内容压缩后存进.git/objects目录然后在暂存区index里记录“文件名 - blob哈希”的映射。注意这一步只处理了文件内容还没处理目录结构。第二git commit根据暂存区的状态生成一个tree对象。tree对象描述目录结构哪个目录下有哪些文件每个文件对应哪个blob哪个子目录对应哪个tree。你可以把它理解成快递箱里的装箱清单blob是箱子里的一件件商品。第三创建commit对象本身。commit对象就是一个包含着tree哈希、父提交哈希、作者信息、提交者信息、提交说明的文本块。它像快递面单写着“这一箱东西是谁寄的、什么时候寄的、上一单流水号是多少”。第四更新当前分支引用。.git/refs/heads/main这个文件里存的是一个哈希值Git把这个值指向刚刚创建的commit对象。HEAD再指向refs/heads/main。这里要重点说一个很多人误解的点**Git保存的不是差异而是快照。**SVN记录的是文件改动了哪几行Git记录的是“这次提交后整个目录长什么样”。commit对象就是这次快照的门牌号。所以git diff对比两个提交时需要先分别取出两个commit指向的tree再逐层对比最终算出差异。这也是为什么Git切换分支、查看历史非常快——大多数时候只是指针移动文件直接按快照铺开不需要拼凑增量。1.2 解剖一个真实的提交对象光说不练没用我带你亲手解剖一个。建一个演示仓库任意目录都行mkdir git-commit-demo cd git-commit-demo git init git branch -M main # 老版本Git init默认master统一改成main echo hello a.txt git add a.txt git commit -m first commit git cat-file -p HEADgit cat-file是Git的底层命令plumbing-p表示友好地打印对象内容。你会看到类似这样的输出tree 8f14150f0c82893d82d711371b26b9a9f53544a5 author demo demoexample.com 1731234567 0800 committer demo demoexample.com 1731234567 0800 first commit这就是一个commit对象的全部内容本质就是一段文本。逐字段来说tree指向本次提交对应的tree对象也就是整个项目目录快照的根节点。parent父提交哈希。如果是第一个提交这个字段不存在后续提交会有一行或多行parent。author作者。实际写这些代码的人。committer提交者。最后一次处理这个提交的人。乍看两者很像但场景不同你rebase别人的提交时author还是原作者committer变成你。这也是为什么查看提交时Git会分别显示两种身份。空行之后是提交说明message。想确认这个对象确实是“对象模型”的一员可以再用两条命令git cat-file -t HEAD # 输出 commit git cat-file -s HEAD # 输出对象字节数HEAD在这里只是个入口先指向分支引用再找到commit对象。你还可以直接指定某个哈希查看git cat-file -p 8f14150这样的效果一样。提交对象不是藏在某个神秘数据库里的大结构体它就是一个可以用cat-file打印出来的文本块再加了一层压缩和哈希命名而已。2. 提交对象是怎么生成和存储的2.1 内容寻址哈希就是对象的身份证Git是内容寻址系统这句话是理解一切的基础。所谓“内容寻址”就是拿着内容本身做哈希用哈希当文件名、当地址。Git的对象存储路径固定为.git/objects。松散对象loose object的物理布局是.git/objects/ab/cdef...其中哈希前两位作为子目录名剩下38位作为文件名。我手动算过一次流程如下把对象序列化成固定格式对象类型 字节数\0原始内容比如blob对象就是blob 5\0hello。对这个格式化后的字节串做SHA-1哈希新版Git也支持SHA-256git init --object-formatsha256可以开启。用zlib压缩整个字节串写入.git/objects/ab/cdef...。用一条命令就可以验证“内容决定地址”echo hello | git hash-object --stdin -t blob这行命令不会写任何文件只是把hello的blob哈希打印出来。你会发现只要输入一致输出永远一致。这个特性的直接收益是去重你在10个目录里各放一份相同内容的文件Git只会保存一个blob对象。两个commit的tree即使内容完全一样tree的哈希也一样Git不会重复存储。“内容变了哈希就变旧对象原地保留”这一点我认为是Git最优雅的设计。它意味着对象一旦生成就永远存在不可变、不会悄悄被覆盖。想回到任何旧状态只需要找到旧commit的哈希Git就可以沿着tree找到当时全部的blob。回滚、分支、协同看似复杂的操作放到这个模型下就会清晰得多。2.2 手搓一个提交对象彻底搞懂git commit接下来是最有意思的部分不用git commit手搓一个提交对象出来让Git承认它。实验前先确认你已经配置了user.name和user.email否则底层命令会因为缺少身份信息而报错。方法A使用底层命令复刻git commit的流程。mkdir auto-commit cd auto-commit git init git branch -M main git config user.name demo git config user.email demoexample.com echo hello a.txt git add a.txt tree$(git write-tree) echo tree hash: $tree commit$(git commit-tree $tree -m first commit) echo commit hash: $commit git update-ref refs/heads/main $commit git log --onelinegit write-tree根据当前暂存区生成tree对象并返回哈希git commit-tree根据tree哈希和message创建commit对象写入对象库后打印哈希git update-ref refs/heads/main 哈希把分支引用指向这个新的commit对象。最后git log能看到一个正常的提交和用git commit创建的没有区别。方法B更硬核一点完全手工构造commit文本。tree$(git write-tree) timestamp$(date %s) printf tree %s\n $tree /tmp/commit.txt printf author demo demoexample.com %s 0800\n $timestamp /tmp/commit.txt printf committer demo demoexample.com %s 0800\n $timestamp /tmp/commit.txt printf \nfirst commit (handcrafted)\n /tmp/commit.txt hash$(git hash-object -t commit -w --stdin --literally /tmp/commit.txt) echo $hash git update-ref refs/heads/main $hash git log --all -p方法B的关键是git hash-object -t commit -w --stdin --literally从标准输入读取已经是“commit格式”的文本当成commit对象压缩写入对象库并计算哈希。--literally这个选项在较老的Git版本里可能没有如果报错用方法A也一样。我实际测试时发现手工构造的commit完全可以被git log、git show正常解析这就是“commit对象只是文本”的最好证明。知道了这一层你再看git commit那种高层命令就不会发怵了——所谓porcelain命令本质就是把hash-object、write-tree、commit-tree、update-ref这些plumbing命令串起来的自动化脚本。3. parent指针、分支与提交图3.1 提交链与分支引用commit对象里有一行或多行parent这是构建历史的关键。根提交没有parent普通提交有一个parent合并提交merge commit有两个甚至更多parent。所有提交通过parent指针连成一个有向无环图DAG。用文字表示一个典型场景A --- B --- C main分支 \ D --- E feature分支B有两个孩子C在main上D在feature上。merge之后A --- B --- C --- M \ / D --- EM就是一个有多个parent的合并提交。你可以用git cat-file -p M的哈希看到两行parent。分支这个东西在底层极其朴素.git/refs/heads/main这个文件里就是一行哈希。所谓创建分支就是新建一个文件、写一个哈希所谓删除分支就是删文件。这就是为什么Git里创建分支几乎瞬时完成——它不拷贝任何文件只记录一个指针。HEAD则是一个符号引用内容通常是ref: refs/heads/main它告诉你当前站在哪个分支上。git switch相当于是把HEAD指向另一个分支引用。理解这一层后我再看git branch -d之后“分支没了”总感觉丢东西的心态就放平了只要提交对象还在分支只是一个可以随时重建的标签。真正的数据是那一颗颗不可变的commit节点和它们指向的tree、blob。3.2 amend、rebase、cherry-pick的本质都是“新建提交”哈希不可变、对象不可改那么想“改”历史怎么办答案只能是用新对象替代旧对象再移动引用。三个高频操作全都是这个套路。先看git commit --amend网上经常搜“git commit --amend怎么使用”。实际做法git commit -m v1 hash1$(git rev-parse HEAD) git commit --amend -m v1 amended hash2$(git rev-parse HEAD)你对比hash1和hash2就会发现它们绝对不一样。原因很简单commit对象内容里含message、时间戳、committer信息任何一项变了整个对象的哈希就变了。amend的本质是“基于当前commit生成一个新的commit对象然后把分支引用从旧的移到了新的”。旧对象去哪儿了还在对象库里待着只是暂时没有引用指向它成了悬空对象。这部分我在第4节详细说。git rebase同理。它把一串提交从旧基础上摘下来在目标基础上“重放”一遍。重放意味着每个提交都生成新的commit对象。rebase之后author通常保持原样但committer时间和提交者会更新所有哈希都变了。这就是为什么push之后rebase会产生“历史分裂”远端会拒绝普通的push只能force push。git cherry-pick本质也类似把某个commit的改动应用过来生成一个新的commit对象。新对象拥有新的哈希、新的committer甚至message都可能不同。用一张表把三者说清楚操作是否新建commit对象authorcommitter风险关注点git commit --amend是1个保持不变更新改写已推送历史的起始点git rebase是每个提交都新建保持不变更新已推送分支被改写需要强推git cherry-pick是1个通常保留原author更新注意提交信息是否需要修正一句话总结Git历史不可改写只能新建。我遇到无数人卡在“为什么我改了提交信息远端不让我push”这个问题上根因就在这里。4. 悬空提交与对象回收4.1 误删的提交去哪了reflog与fsckcommit对象一旦生成就不可变、也不会主动消失。那被amend、reset、rebase丢掉的老提交去哪了答案是它们在对象库里还占着一个位置只是没有分支引用指向它们处于“不可达”状态。Git的垃圾回收不会立刻清理它们因为你还可能想找回。所以误删提交后的第一反应不要慌先看refloggit reflog -5reflog记录的是本地引用HEAD、分支最近的变化历史。比如你执行了git reset --hard HEAD~1原先HEAD指向的提交并不消失在reflog里它还在HEAD{1}。想回去就执行git reset --hard HEAD{1}我实际用这个姿势救回过一次工作区。当时连续写了三四个提交后感觉路子不对直接reset回两天前结果发现还是原来的方案更完善想恢复时人已经慌了。后来通过reflog一步一步倒着找终于在HEAD{5}那里翻到了当时的提交哈希一个reset就全部恢复。前提是中间不要触发gc清理尤其不要手动git gc。reflog默认有90天过期时间时间久了也会被清掉所以发现丢东西后尽早操作。还有一个底层工具git fsck专门检查对象库完整性也会列出“悬空”dangling对象git fsck --lost-found输出里能看到dangling commit 哈希值。这些就是没有引用但从对象库里还能找到的提交。配合git show 哈希值你可以查看它们的内容再把分支指过去。fsck更常见的价值是排查仓库损坏后面第5节我会专门讲。4.2 从松散对象到packfile对象库不是永远只放一堆松散文件。提交越来越多后.git/objects会塞满大量独立的小文件既占inode又浪费空间。Git会在合适的时机比如git gc、某些自动维护把这些松散对象打包成packfile压缩率非常高同时生成一个.idx索引文件供快速查找。想观察仓库的存储状态可以用git count-objects -v其中count字段显示松散对象数量size-pack显示打包文件的大小。我见过有人误以为git gc是“清理垃圾”跑完发现什么提交都在怀疑gc没生效。其实gc默认清理的是“确实不可达且超过保留期限”的对象以及过期reflog。它不是你改历史后立刻消失数据的手段反倒是你误删后不要乱跑的命令。另外还有一层优化叫commit-graph。Git 2.18以后可以把提交图写入.git/objects/info/commit-graph文件加速提交链的遍历git log、git merge --is-ancestor这些操作会明显变快。手动生成可以执行git commit-graph write日常自动维护也会更新。理解提交对象的parent链之后再看commit-graph就很好懂它就是把这颗链的拓扑信息提前算好存起来省得每次现走图。5. 提交对象相关的常见问题与避坑指南5.1 改message后远端push被拒是怎么回事这个问题几乎天天有人问“我改了最后一次提交的messagecommit --amend为什么push的时候被拒绝”看了前面的原理原因已经很明显amend之后你本地main指向的是一个新的commit对象而远端main还指向旧的commit对象。在Git看来你的本地历史“偏离”了远端的旧历史普通push会被拒绝因为那相当于把远端历史改写掉。这里我建议按情况处理如果这个分支只有你自己在用且没有其他人clone过可以直接git push --force-with-lease。加--force-with-lease是为了防止在你push之前远端被其他人更新过安全性比--force高很多。如果分支已经公开、团队协作千万不要rebase或amend后强推那会让别人的本地历史瞬间“找不到共通祖先”。这时候用git revert生成一个反向提交来修正内容虽然会留下多一条提交记录但历史是线性连贯的所有人都能顺利同步。表格总结“改写历史”的适用场景分支状态推荐方案原因未push的本地提交commit --amend、rebase随便用远端不存在旧对象无冲突已push但只有自己在用force-with-lease小心强推需要同步远端历史公开协作分支revert禁用强推避免其他协作者历史分裂5.2 .git目录泄露为什么等于源码泄露提交对象模型有一个必须正视的安全推论Git对象只是压缩不是加密。看本文前面的内容你就明白commit对象、tree对象、blob对象都是明文文本经过zlib压缩后存放的任何能读取.git/objects目录的人都可以用git cat-file把对象内容还原出来。“Web服务器把.git目录暴露出去”这类事故本质上等于把整个源码库和全部历史提交都送给了攻击者。网上常有人搜“git目录泄露如何下载”其实原理我在前面都讲过了从.git/refs/heads/main读取当前分支指向的commit哈希顺着parent链把所有commit都找出来再用每个commit的tree哈希找回全部目录结构和文件blob一套MapReduce仓库历史就完整重建了。甚至就算某个对象缺失因为哈希是内容寻址的攻击者对常见文件名做哈希猜测也有可能命中。防御方案没那么神秘Web服务器层面禁止访问任何以.git开头的路径。部署时使用构建产物/发布包不要把仓库原样拷到Web目录。密钥、Token、数据库口令绝对不提交到Git仓库。一旦提交过哪怕后来删除文件再commit历史blob仍然存在等于密钥已经泄露必须立即轮换。我见过有人把.env提交上去删掉后以为没事结果用git log --all -p一搜历史里白纸黑字全在。本地“清除账号密码”的需求应该区分两层网络凭据用git config --unset credential.helper或系统的凭据管理器清掉这个管的是push/pull的登录信息仓库里已经写入的敏感内容则要用git filter-repo重写历史并配合全员force push才可能真正抹掉。前者和安全无关后者才是真正的清洗。5.3 对象损坏或仓库不完整时如何自救还有一种让人头皮发麻的情况Git突然报错error: object file ... is empty、fatal: bad object之类。意思是某个commit或blob对象读不出来要么文件被截断要么被其他程序误改过。这时候“对象不可变”的反面就体现出来了缺一个对象整条历史链就断了一环。我的排查路线先备份整个.git目录任何修复动作之前都要先留后路。跑git fsck --full它会逐个对象检查明确指出哪个哈希缺失/损坏是missing blob还是corrupt commit。如果仓库内容在远端还有备份最简单粗暴的方案是直接从远端重新clone或fetch用远端补回缺失对象。本地独有的未push提交如果对象坏了基本就只能靠reflog、dangling commit碰运气了。如果只是某个松散对象文件是空文件而你在备份里能找到对应哈希的对象文件也可以复制回去。我自己的经验是objects目录是Git仓库的心脏备份仓库时至少要把.git/objects和.git/refs保住或者干脆用git bundle做打包备份。另外一个更早的止损点是坚持push到远端真出事时远端就是最大的保险。顺带解释一个热搜命令报错fatal: not a git repository (or any of the parent directories): .git。Git在任何命令执行前都要找到仓库根目录的.git它会从当前目录一路向上级目录查找。找不到就会这样报错。这个错误和对象损坏无关本质是“当前目录不在此仓库范围内”比如你进了子目录但目录没初始化或者把仓库文件夹只复制了一部分。git init或换到正确的仓库目录即可和第5.3节说的对象损坏是两码事。我个人做完这一整套实验最大的体会是别再被git log里那串神秘的十六进制吓到它只是一个文本块的指纹。你越是理解提交对象越会发现Git所谓的神秘高级功能都只是“对象不可变 引用可移动”这两个核心规则的不同排列组合。下次再遇到历史操作问题先问自己一句这里新建了哪些对象移动了哪些引用答案往往立刻清晰。