当前位置：首页 > news >正文

如何详细理解 Git 工作原理？

news 2026/5/16 1:22:57

理解 Git 工作原理的核心在于搞清楚它的存储模型和三个工作区域，这能帮你在遇到合并冲突或数据丢失时快速找回状态，而不是盲目重试命令。

先说结论：掌握 Git 的快照存储机制和对象结构，比死记硬背命令更能解决复杂问题。

适合：经常遇到合并冲突、需要恢复误删代码或想深入理解版本控制的开发者
先看：工作区、暂存区和本地仓库的数据流向，以及 blob、tree、commit 三种对象
建议：通过 git cat-file 查看底层对象内容，验证你对提交历史的猜想

核心机制：快照而非差异

Git 与其他版本控制系统最大的区别在于它对待数据的方式。大多数系统（如 SVN）以文件变更列表的方式存储信息，而 Git 更像是把数据看作是对小型文件系统的一系列快照。每次提交更新时，Git 会对当时的全部文件创建一个快照并保存这个快照的索引，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。

此外，Git 的操作绝大多数都是本地执行的。因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成，不需要外连到服务器去获取历史。数据存储在项目根目录的.git 隐藏文件夹中，采用键值对方式，key 是数据的 SHA1 哈希值，value 是实际数据内容。

实操：查看底层对象

可以通过以下命令直观感受 Git 的存储机制，观察对象哈希与内容的对应关系：

# 初始化仓库
git init# 创建测试文件
echo "Hello Git" > test.txt# 计算文件哈希并写入对象库（不暂存）
git hash-object -w test.txt# 查看对象类型
git cat-file -t <上一步输出的哈希># 查看对象内容
git cat-file -p <上一步输出的哈希>

命令输出示例：

$ git hash-object -w test.txt
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391$ git cat-file -t e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
blob$ git cat-file -p e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Hello Git

实战：手动构建 Git 对象

为了深入理解，我们可以手动创建对象并观察 .git/objects 目录结构的变化：

创建 Blob 对象：使用 git hash-object -w 将内容写入对象数据库。
查看目录结构：Git 会将哈希值的前两位作为目录名，后 38 位作为文件名。

# 查看 objects 目录结构
find .git/objects -type f | head# 输出示例
.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
.git/objects/info/commit-graph
.git/objects/pack/pack-.idx

可以看到文件被存储在 .git/objects/e6/ 目录下，文件名是哈希值的剩余部分。这是 Git 压缩存储的基础结构。

怎么验证是否生效

使用 git log 查看提交历史，确认提交 ID 和提交信息是否符合预期。使用 git cat-file -p <commit_hash> 可以查看提交对象的详细内容，包括树对象哈希、父节点哈希、作者和提交时间。

# 查看最新提交对象的内部结构
git cat-file -p HEAD# 输出示例
tree 85e4c7724aae9e2ebf5e3f5d5c5e5e5e5e5e5e5e
parent 9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b
author Developer <dev@example.com> 1678888888 +0800
committer Developer <dev@example.com> 1678888888 +0800Initial commit

如果能看到对应的 blob 和 tree 对象内容，说明底层存储正常。