Git版本控制与团队协作教程

00 教程导读：像侦探一样读懂 Git

一句话定位：这是一部从 .git 目录的对象库出发、用底层机制解释一切上层命令行为的 Git 教程。我们不背命令，我们勘查证据——四种对象、SHA-1 指纹、引用与 HEAD，读懂它们，git merge、git reset、git rebase 这些命令在你眼里将不再神秘。

为什么大多数人的 Git 学不会

很多人学 Git 的路径是这样的：网上找一份"Git 常用命令清单"，把 git add、git commit、git push 三连当咒语背下来。日常够用，直到某一天出事——合并冲突满屏 <<<<<<<，git reset --hard 误删了两小时的工作，或者 rebase 到一半被卡在陌生分支里不敢动。这时候命令清单救不了你，因为你从不知道这些命令到底在动什么。

问题出在学习顺序上。Git 的上层命令是一层"界面"，界面下面是一个设计极其克制的对象模型：整个版本库不过是几十字节的指针文件，加上一堆以 SHA-1 哈希命名的不可变对象。命令只是操作这些对象和指针的快捷方式。不理解模型，命令就是黑盒；理解了模型，每条命令的行为都可以预测。

所以本教程把学习顺序倒过来：先下楼，进入 .git 目录这个"案发现场"，亲手用 git cat-file 打开一个个对象看清它们的真身，再回到楼上用日常命令。你会发现，分支只是一个 41 字节的文本文件，HEAD 只是引用的引用，合并冲突不过是两个提交抢同一个 tree 位置。破案之后，恐惧自然消失。

对象模型侦探的方法论

本教程的叙事主调是"对象模型侦探"。每一章都是一次完整的勘查，遵循固定却自然的推理链条：

1. 取证：跑一条底层探查命令（git cat-file -p、git ls-tree、git rev-list），拿到原始证据——对象内容、哈希值、指针指向。
2. 推理：从证据推出机制——这个命令改写了哪个文件？新建了哪个对象？移动了哪个指针？
3. 结案：把机制翻译回日常命令——现在你明白了 git commit --amend 并没有"修改"任何东西，它只是新建了一个提交并把分支指针挪过去。

这套方法论来自一个朴素的事实：Git 是内容寻址的文件系统加上一层薄薄的版本控制语义。Linus Torvalds 当年就是这么设计它的。你在别的资料里看到的"暂存区""分支""标签"，在这个文件系统里都对应着具体的文件和目录，肉眼可见、文本可读。侦探的放大镜，就是 git cat-file。

全书地图

教程共五章，从对象本体一路讲到团队协作，层层向外扩展：

• 第 1 章 对象库与内容寻址：勘查 .git 目录结构，认识 blob、tree、commit、tag 四种对象，理解 SHA-1 为什么是"内容的指纹"，以及工作区、暂存区、仓库三区如何流转。这是全书的物理基础。
• 第 2 章 引用侦探社：分支只是指针：打开 refs/heads 目录，看清分支不过是写着哈希值的文本文件；HEAD、detached HEAD、合并的两种形态、变基如何改写历史，全部用指针移动来解释。
• 第 3 章 日常操作的证据链：把 status、add、commit、log、diff、reset、checkout、revert 这些高频命令逐一还原成对象与引用的操作，并给出事故排查的证据链思维。
• 第 4 章 远程协作网络：远程仓库在对象模型里只是"带昵称的引用"，fetch、pull、push 的本质是对象同步加引用更新；远程跟踪分支、标签发布也在这一章落地。
• 第 5 章 团队工作流与生态：从集中式、功能分支、Gitflow 到 Forking 四种工作流的对比勘查，到分支策略与团队规范的制定，再到托管平台与工具生态的选择。

全书知识结构一图流

你将获得什么

读完本教程，你应当能做到这些"侦探级"操作：在出事现场不慌不忙地用 git reflog 找回丢失的提交；预判一条命令会创建哪些对象、移动哪些指针；在 code review 时一眼看穿一个合并会把哪些变更带进主线；为三到十人的团队选定一套不折腾的分支规范。

对新手，建议从第 1 章按顺序读，每章的探查命令最好亲手跑一遍——侦探不能只看别人勘查的照片。对有两年以上 Git 使用经验、被 rebase 或冲突折磨过的读者，可以直接跳到第 2 章和第 3 章的撤销部分，那里的对象级解释最能解渴。团队负责人可以重点读第 5 章，把工作流选型当作一次"组织结构勘查"。

全书金句：在 Git 里没有魔法，只有对象和指针。任何看起来玄学的命令行为，都能用"新建了什么对象、挪动了哪个指针"这两句话讲清楚——这正是侦探的办案信条。

还有一个反复被验证的经验值得在开篇交代：Git 几乎从不真正销毁数据。你删掉的分支、reset 掉的提交、amend 掉的旧版本，都以"悬空对象"的形式在对象库里滞留至少两周（直到垃圾回收运行），git reflog 则记录着 HEAD 的每一次移动。这意味着绝大多数"我代码没了"的事故，在对象模型侦探眼里都是可以破的悬案——只要记得案发时间大致范围，证据多半还躺在 .git 里。本教程会反复回到这一点，直到你形成肌肉记忆：动手前先看 reflog，出事后第一时间取证而不是乱试命令。

侦探的办案地图

準备好了吗？带上放大镜，我们进入第一个案发现场：你的项目根目录下那个不起眼的 .git 文件夹。