Git 的内部结构

无论你是循序渐进地学习到这里，还是因兴趣直接跳转到本节，欢迎来到Git的核心部分。在本节内容中，我们将系统性地分析Git的工作原理及其内部机制，深入了解它如何进行版本管理。

在正式开始之前，先举一个开发案例：有开发者在使用Git管理项目时，发现即便删除了一些文件，仓库体积却未明显减小。此类现象的根源其实在于Git的内部数据存储机制。 正如熟悉汽车结构能帮助工程师更高效地处理故障，理解Git的底层实现同样能够帮助开发者在遇到复杂问题时做出更合理的分析与决策。

Git的本质

让我们从一个核心概念开始：Git本质上是一个“内容寻址”的文件系统，上面包装了一层版本控制系统的用户界面。 这句话听起来有点绕，让我用一个简单的比喻来解释。想象一下，你有一个超级智能的储物柜系统。这个系统有一个神奇的特点：你给它任何东西，它都会根据这个东西的内容，计算出一个独一无二的编号。如果你给它同样的东西，它总是会给出同样的编号。

更神奇的是，这个系统永远不会重复存储相同的内容。如果你把同一张照片存了100次，系统只会在储物柜里放一张，但会给你100个指向这张照片的“门票”。 这就是Git的核心思想。它不关心文件名、不关心时间，只关心内容本身。如果两个文件的内容完全一样，Git就认为它们是同一个东西。

Git的两套“语言”

在我们开始深入之前，我需要向你介绍Git的两套命令系统。这就像一座房子有两套系统：一套是你能看到的精美装饰（瓷器），另一套是藏在墙里的管道系统（水管）。

我们日常使用的工具

到目前为止，我们学习的所有Git命令，比如git add、git commit、git branch，都属于“瓷器命令”。它们就像房子里的水龙头、开关、门把手，设计精美，使用简单，让我们能轻松地完成日常任务。 这些命令是Git的“用户友好界面”，它们隐藏了底层的复杂性，让我们专注于我们的工作。

Git的底层工具

但Git还有另一套命令，这些命令就像墙里的水管、电线、管道。它们不那么美观，但它们是整个系统的基础。这些“水管命令”能让你直接操作Git的内部数据结构。 在这一节里，我们将深入“墙壁内部”，探索这些水管命令的秘密。虽然你平时可能不会直接使用它们，但了解它们的工作原理，能让你真正理解Git是如何思考的。

.git文件夹

每当你运行git init命令时，Git都会在你的项目目录里创建一个名为.git的隐藏文件夹。这个文件夹就是Git的“大脑”，所有的魔法都在这里发生。

想象一下，这个.git文件夹就像是一个超级智能的档案室。它里面存放着你的项目的所有历史记录、所有版本、所有配置信息。如果你想要备份你的整个项目历史，理论上你只需要复制这个.git文件夹就够了。

|
.git/
├── HEAD          # 指向当前工作分支的指针
├── config        # 项目的配置文件
├── description   # 项目描述（供GitWeb使用）
├── hooks/        # 钩子脚本目录
├── info/         # 全局忽略文件
├── objects/      # 存储所有数据对象的数据库
└── refs/         # 存储所有引用（分支、标签等）

这些文件和目录中，最重要的是四个：HEAD、objects、refs，以及一个初始时还不存在的index文件。这四个就是Git的“四大支柱”。

Git的三种核心对象

现在，让我们进入Git最核心的部分。Git的世界是由三种基本对象构建起来的，就像乐高积木一样，用这些简单的积木，Git可以构建出复杂的版本控制系统。

Blob对象

首先，我们来认识最基础的Blob对象。Blob是“Binary Large Object”的缩写，但你可以简单地把它理解为一个“内容块”。 想象一下，你写了一首诗，内容是“春眠不觉晓，处处闻啼鸟”。Git会把这首诗的内容（“春眠不觉晓，处处闻啼鸟”）打包成一个Blob对象。 这个Blob对象只关心内容本身，它不关心这首诗叫什么名字，不关心你什么时候写的，也不关心你用什么字体。

这里有一个有趣的现象：如果你的项目里有100个文件，内容都是“Hello, Git!”，Git在存储时只会创建一个Blob对象，然后让这100个文件都指向这个Blob。这大大节省了存储空间。

Tree对象

既然Blob对象只存储内容，那文件名和目录结构是怎么保存的呢？这就是Tree对象的作用。 Tree对象就像是一个文件目录的“快照”。它本身不存储文件内容，而是像一张清单，记录着某个文件夹在某个时刻的状态。 这张清单上的每一行都包含：

• 一个指向Blob对象（文件）或另一个Tree对象（子目录）的SHA-1哈希指针
• 对象的类型（是blob还是tree）
• 对象的权限模式（比如100644表示普通文件）
• 文件名或目录名

所以，一个Tree对象就定义了一层目录结构。如果你的项目有复杂的嵌套目录，那么它就会由多个Tree对象相互引用构成。

Commit对象

现在我们有了文件的内容（Blob）和项目的目录结构（Tree），但还缺少版本控制的关键信息：谁在什么时间、因为什么原因，创建了这个项目快照？

这就是Commit对象的作用。一个Commit对象就像是版本历史中的一个“时间切片”，它记录了一次提交的所有关键信息。 具体来说，一个Commit对象包含：

• 一个指向项目顶层Tree对象的SHA-1哈希指针（代表本次提交的完整项目快照）
• 一个或多个指向父提交的SHA-1哈希指针（构建历史链条的关键）
• 作者和提交者的信息（姓名、邮箱、时间戳）
• 提交信息（你写的那些描述）

现在，整个画面清晰了。Git的历史，就是由一个个Commit对象串联起来的链条。每个Commit都指向一个完整的项目快照（Tree），而Tree又组织了所有的文件（Blob）。

引用系统

到目前为止，我们已经理解了Git是如何通过Commit、Tree、Blob这三种对象来存储项目历史的。但问题来了：我们总不能去背那一长串40个字符的SHA-1哈希值来找到某次提交吧？ 这就像你有一个超级大的图书馆，每本书都有一个很长的编号，但你总不能每次都去背这些编号吧？你需要给重要的书起个简单的名字，比如“我最喜欢的书”、“工作参考书”等等。 这就是“引用”（References）的作用。

分支

在Git中，一个分支的本质，其实就是一个指向某个Commit的、可以自由移动的指针。它并不是像其他版本控制系统那样，是整个项目代码的物理拷贝。 当你创建一个新分支时，比如git branch feature，Git所做的，仅仅是在.git/refs/heads目录下创建一个名为feature的文件，然后把当前Commit的哈希值写进去。就是这么简单！ 当你在这个新分支上工作，并创建了一个新的提交时，Git会自动将feature文件里的哈希值，更新为这个最新提交的哈希值。所以，分支指针会永远随着你的工作进度，自动指向当前分支的最新一次提交。

标签

标签与分支类似，也是一个指向特定Commit的引用。但它们之间有一个关键区别：分支指针是“动态”的，会随着新的提交而移动；而标签是“静态”的，一旦贴上，就永远固定在那个Commit上。

这使得标签非常适合用来标记重要的里程碑，比如v1.0、v2.1.3这样的发布版本。

HEAD

现在我们有了分支和标签这些书签，但Git还需要知道你当前正在翻阅哪一页。这个“你当前的位置”指示器，就是HEAD文件。 HEAD文件通常是一个“符号引用”。它自己不直接存储Commit的哈希值，而是指向另一个引用，通常是一个分支。比如，当你checkout到master分支时，.git/HEAD文件的内容会是ref: refs/heads/master。 这意味着HEAD正指向master分支。当你执行git commit时，Git就知道：

1. 找到HEAD指向的master分支
2. 读取master分支指针所指向的那个Commit，作为新提交的父提交
3. 创建新的Commit对象
4. 最后，移动master分支的指针，让它指向这个刚刚创建的新Commit

所以，HEAD → master → 最新Commit，这就是Git工作时最核心的指针链条。

优化存储

随着项目越来越大，历史越来越长，.git/objects目录下的零散对象文件可能会变得非常多，这会降低文件系统的效率。Git通过Packfile机制解决了这个问题。

Packfile

假如你正准备搬家，有很多书要打包。如果每本书都单独包装，会占用很多空间。一个聪明的办法是，把相似的书放在一起，用压缩袋抽掉空气，这样就能节省很多空间。 Git的Packfile机制就是基于类似的思想。Git不会一直以松散的对象文件形式存储所有对象。当松散对象的数量达到一定规模时，或者你手动执行git gc命令时，Git会启动“打包”程序。

这个过程非常智能。首先，它会找到所有相关的对象（Commit、Tree、Blob）。然后，为了极致地压缩空间，它会寻找相似的文件，比如你某个文件的不同版本。它不会完整地存储每个版本，而是将一个版本作为基础，然后只记录其他版本与它之间的差异。 最后，所有这些对象和差异数据，会被压缩并打包成一个二进制文件，即Packfile（.pack），同时还会生成一个配套的索引文件（.idx），以便能快速地在Packfile中定位和解压出任何一个对象。

数据传输

当你执行git fetch、git pull或git push时，你的本地Git是如何与远程服务器交换数据的呢？这依赖于一套智能的传输协议。 想象一下，你和一个朋友要交换书籍。如果你们都很聪明，你们会先看看对方有什么书，然后只交换那些对方没有的书，而不是把所有的书都搬来搬去。 Git的智能协议就是这样工作的。当你向远程仓库fetch数据时，它会这样做：

1. 你的本地Git会先和远程Git打个招呼，说：“你好，我想更新一下数据”
2. 远程Git会发回一份“菜单”，上面列出了它所有的分支和标签，以及它们各自指向的最新Commit哈希
3. 你的本地Git会对照一下自己本地已经有的Commit，然后告诉远程Git：“我想要从A到C之间的所有东西，其他的我都有了”
4. 远程Git收到这个“订单”后，就会把本地Git缺失的对象打包，然后一次性发给它

这个过程非常高效，因为它只传输你本地没有的数据，避免了任何不必要的网络流量。

仓库维护

在我们的Git探险旅途中，有时候可能会遇到一些意外情况，比如误删了分支，或者想从历史中彻底移除一个不小心提交的大文件。别担心，Git提供了强大的工具来应对这些状况。

git gc：

git gc（Garbage Collection）命令就像是给Git仓库做一次彻底的“大扫除”。它不仅会打包对象以节省空间，还会查找那些在仓库中已经没有任何引用指向的“悬空”对象。 这些对象通常是在你进行rebase、reset等操作后被“抛弃”的旧Commit。Git并不会立即删除它们，而是会给它们一个宽限期（通常是几周）。在gc运行时，如果这些对象过了宽限期，就会被彻底清理掉，从而释放磁盘空间。 通常，Git会在后台自动运行gc，你很少需要手动执行它。

git reflog

想象一下，你刚刚用git reset --hard命令，不小心把一个分支的最新几个提交给弄丢了。或者，你删掉了一个开发了很久的分支，然后才发现里面有你需要的代码。这时候，reflog就是你的救命稻草。 reflog，即“引用日志”，是Git的一个秘密武器。它默默地记录着HEAD指针在过去一段时间内的每一次移动。每当你checkout、commit、reset或branch时，reflog都会记下一条日志。

这个日志只存在于你的本地仓库，不会被推送到远程，它就像一个专属于你的操作历史记录。当你丢失了Commit时，只需运行git reflog命令，你就会看到一个列表，展示了HEAD最近的移动轨迹。

你可以从中找到你丢失的那个Commit的哈希值，然后像施展魔法一样，用git checkout或git branch命令，让它“复活”。

filter-branch

有时候，我们会犯一个严重的错误：不小心把一个巨大的二进制文件（比如一个视频或者一个依赖包）提交到了Git历史中。即使你在下一个Commit中把它删除了，这个大文件依然静静地躺在你的.git/objects目录里，因为Git的历史是不可变的。 这意味着，任何克隆你仓库的人，都将被迫下载这个无用的大文件，导致仓库变得异常臃肿。

要解决这个问题，你需要重写历史，将这个文件从所有相关的Commit中彻底抹除。git filter-branch就是为此而生的终极武器。这个命令非常强大，但也非常危险，因为它会彻底改写你的提交历史。 使用filter-branch，你可以指定一个脚本，Git会用这个脚本去检查从创世以来的每一次提交。如果脚本发现某个提交中包含了你想删除的文件，它就会把这个文件剔除，然后重新生成一个新的Commit来取代旧的。

这个过程会改变所有受影响的Commit的SHA-1哈希值。因此，在你重写历史之后，你必须强制推送（force push）到远程仓库，并且通知所有协作者，让他们重新基于你新的历史进行工作。 这是一个非常有破坏性的操作，只应在万不得已，并且与团队充分沟通后才能使用。

理解Git的思维方式

现在，我们已经一起探索了Git的内部世界。从最基本的三种对象（Blob、Tree、Commit），到引用系统，再到存储优化和数据传输，我们看到了Git是如何思考的。 理解这些内部机制，不仅能让你在遇到问题时更加从容，还能让你更好地理解Git的设计哲学。Git的每一个设计决策，都是为了解决版本控制中的实际问题。

记住，Git不是一个神秘的黑盒子，而是一个精心设计的系统。它的每一个部分都有其存在的理由，每一个机制都是为了让版本控制变得更加高效和可靠。 当你下次使用Git时，试着想象一下背后发生了什么。想象那些对象是如何被创建和存储的，想象那些指针是如何移动的，想象那些数据是如何被压缩和传输的。这样，你就能真正地“理解”Git，而不仅仅是“使用”Git。