为何 Git 搞那么复杂？

为何 Git 搞那么复杂？

先说结论：Git 的复杂不是设计失误，而是 20 年历史层层堆叠的地质沉积。 每一层复杂都有它的道理，但这些道理叠在一起，就成了新手的噩梦。要真正理解这个问题，得从 Git 诞生前的版本控制史说起。

▶ 在 Git 之前，版本控制经历了什么

很多人以为版本控制天生就该长 Git 这样。其实在 Git 出现前，这个领域已经迭代了四代产品，每一代都在解决上一代的痛点，也都在埋下新的坑。

版本控制工具演进史

最早的 RCS（1982 年）用悲观锁机制，同一时间只有一个人能编辑一个文件，改完了别人才能动。这在小团队勉强能用，项目一大就成了瓶颈。CVS（1986 年）引入了乐观并发，允许多人同时编辑同一个文件再合并，但它是按单文件追踪版本的，没有项目级别的原子提交。你改了三个文件，提交到一半网络断了，仓库就处于一个不一致的状态。更要命的是，CVS 的分支操作极其痛苦，Linus Torvalds 后来吐槽说用 CVS 建个分支「需要提前规划一周，再专门花一天来执行」。

Subversion（2000 年）修复了原子提交和目录版本化的问题，成为 CVS 的「正统继承者」。但 SVN 骨子里还是中心化架构，所有历史都存在中央服务器上。断网了你连 svn log 都跑不了，更别说离线提交。对于 Linux 内核这种全球分布式协作的超大项目，SVN 根本不够用。

真正让 Linus 开了眼的是 BitKeeper，Larry McVoy 做的商业分布式版本控制系统。2002 年 Linux 内核开始用 BitKeeper，Linus 后来承认这是第一个让他觉得「版本控制原来有意义」的工具。但 BitKeeper 的免费社区版附带了严格的许可限制：不能参与开发竞品 VCS，元数据要发回 BitMover 服务器。Richard Stallman 把这叫「鞭子的精神」。

▶ 十天造出来的「地狱信息管理器」

2005 年 2 月，Samba 的作者 Andrew Tridgell 对 BitKeeper 的协议做了逆向工程，Larry McVoy 直接撤销了免费许可。Linux 内核团队一夜之间失去了版本控制工具。

2005 年 4 月 6 日，Linus 在内核邮件列表发了封邮件：「内核团队正在寻找替代方案」。他直接排除了 Subversion（原话是「别跟我提 subversion」），考虑过 Monotone 但嫌它太慢。第二天，4 月 7 日，他提交了 Git 的第一个 commit：1244 行 C 代码，10 个文件，commit message 写的是「Initial revision of 'git', the information manager from hell」。到 6 月 16 日，Git 已经能管理内核 2.6.12 的发布了。7 月 26 日，Linus 把维护权交给了 Junio Hamano，至今仍由他负责。

从写第一行代码到管理世界最大的开源项目，总共两个多月。这个速度本身就解释了很多后来的问题。

Linus 给 Git 定了四条硬性设计标准，他管这叫 WWCVSND（What Would CVS Not Do，CVS 不会做的事情就是我要做的）：

速度必须极快。 合并一个 patch 不能超过 3 秒。当时的工具需要 30 秒一个 patch，同步 250 个 patch 意味着等两个小时。对于每天处理上千个 patch 的内核维护者来说，这不可接受。

必须是分布式的。 每个开发者都有完整仓库，不依赖中央服务器，不存在「提交权限」的政治问题。

数据完整性用密码学保证。 每个对象都用 SHA-1 哈希标识，任何比特级别的篡改都能被检测到。Linus 的原话是：「如果你不能保证我放进去的东西取出来完全一样，你就不值得用。」

非线性开发必须是一等公民。 分支和合并必须极度廉价，因为「一个改动被合并的次数远多于它被编写的次数」。

在 2007 年那场著名的 Google Tech Talk 上，Linus 毫不客气地点评了竞品。说 Subversion 是「有史以来最无意义的项目」，对 Google 内部用的 Perforce 表示「我很抱歉」。至于为什么把项目叫 Git（英语俚语里是「讨厌鬼」的意思），他说：「我是个自大的混蛋，所有项目都用我自己命名。先是 Linux，现在是 Git。」

▶ 四个架构决策，每个都合理，叠在一起就要命

Git 的复杂性集中在四个核心设计决策上。 单独看每一个都很精妙，但它们的累积效应造就了陡峭的学习曲线。下面这张图展示了这四层复杂度如何从底向上叠加，每一层都在增加一个新的认知维度：

Git 四层复杂度叠加

第一层：内容寻址的对象存储。 Git 的底层其实是一个键值数据库。每个对象（blob 存文件内容、tree 存目录结构、commit 存提交信息、tag 存标签）都用其内容的 SHA-1 哈希值作为唯一标识。相同内容永远产生相同哈希，这带来了天然的去重、完整性校验和分布式身份认证。但代价是什么呢？用户面对的是 40 个字符的十六进制字符串，而不是 SVN 那种直觉的递增版本号。文件名不存在 blob 里（存在 tree 对象里），所以重命名追踪只能靠启发式算法猜。整个历史形成一棵 Merkle 树，改动任何一个历史 commit，后续所有 commit 的哈希都会变，这就是为什么 rebase 会「改写历史」。

第二层：DAG（有向无环图）提交模型。 中心化 VCS 维护线性历史：版本 1、2、3……Git 的 commit 组成一个图结构，每个节点指向一个或多个父节点。分支只是这个图上的可移动指针，创建一个分支就是往文件里写 41 个字节，几乎零成本。但这也引入了非线性历史、多父节点的 merge commit、「detached HEAD」这种让新手一脸懵的概念，以及 merge（保留图的真实形状）和 rebase（把图改写成直线）之间的哲学争论。

用 Git 自己的提交图来对比就非常直观。SVN 的历史永远是一条直线，而 Git 的历史天然就是一张图：

Git 提交图 DAG 示例

SVN 看到的是 r1、r2、r3……一条干净的直线。Git 看到的是上面这张图：两条 feature 分支从 main 岔开，各自发展，再合并回来。图结构信息量更大，但认知负担也更大。每个 merge commit 有两个父节点，git log 的输出顺序变得不确定，revert 一个 merge 需要指定 -m 1 还是 -m 2 来选择保留哪一侧。这些概念在线性历史里根本不存在。

第三层：暂存区（staging area）。 这是 Git 最独特也最令人困惑的设计。SVN 里 commit 直接提交所有改动，Git 要求你先 git add 把改动放进暂存区，再 commit。这让你能做外科手术式的精确提交，用 git add -p 甚至可以只提交一个文件里的部分改动。但这意味着同一个文件可以同时存在三个不同版本：工作目录一个、暂存区一个、HEAD 里一个。更要命的是，这个概念有三个名字在不同场景混用：「staging area」「index」（文件叫 .git/index）和「cache」（参数叫 --cached）。知乎上有个评论精确地表达了这种困惑：「cache, stage, index, working tree，都是干嘛的？」

下面这张流程图展示了 Git 的三树模型中数据是如何流动的，以及每个操作对应哪棵「树」的变化：

Git 三树模型数据流

SVN 的世界只有两个状态：你的工作副本和中央服务器。一个 svn commit 搞定。Git 硬生生在中间插了一层暂存区，又在远端加了一层远程仓库。每多一层，操作命令就多一倍，出错的可能性也多一倍。

第四层：分布式模型本身的固有复杂度。 SVN 只有一个仓库一份历史，svn update 一把搞定同步。Git 有本地仓库、远程仓库、本地分支、远程追踪分支（origin/main 和 main 是两回事），以及一套多步同步协议。git fetch（只下载不合并）和 git pull（下载 + 合并）的区别在 SVN 世界里压根不存在。再加上 git pull --rebase、fast-forward merge、force push、rebase 后的历史分叉……可能的状态组合远超中心化模型所能产生的。

下面这张架构图展示了 Git 分布式模型的完整拓扑。注意 SVN 里只需要关注「我」和「服务器」两个节点，而 Git 的每个开发者都是一个完整的节点：

Git 分布式模型拓扑

说白了，这四层每一层都在增加维度。对象存储加了一维（内容哈希），DAG 加了一维（非线性历史），暂存区加了一维（三树状态），分布式加了一维（本地 vs 远程）。四个维度叠加的复杂度，是指数级增长的。

▶ 从没被设计过的命令行界面

如果说架构层面的复杂是「必要的代价」，那 Git 的命令行界面就是纯粹的历史债务。

关键背景是：Linus 一开始就没打算做用户界面。 他造的是一套底层文件系统工具，只有七个低级命令（write-tree、commit-tree、cat-file 之类），他称之为 plumbing（管道层）。用户友好的界面叫 porcelain（瓷器层），他期望别人来做。Git 诞生的第一周，Linus 自己就是手动调用这些底层命令来操作仓库的。

Petr Baudis 很快启动了一个独立的 porcelain 项目叫 Cogito。但问题来了：用户友好的命令开始慢慢渗透进 Git 核心本身，git diff、git commit 这些「高级」命令逐渐被加了进来。到 2007 年 Cogito 废弃，Git 自己既是管道又是瓷器，大约 146 个命令，一半底层一半高层，没有统一的 UX 设计准则来管这一切。

这导致了一系列让人哭笑不得的不一致。Steve Losh 在 2013 年写了篇著名的讽刺文章叫 "Git Koans"（Git 公案），用禅宗公案的形式揭露 Git 的荒诞。其中最出名的一则叫「The Hobgoblin」：列出所有 tag 用 git tag（不带参数），列出所有 remote 用 git remote -v（带 -v），列出所有 branch 用 git branch -a（带 -a），查看当前 branch 要用 git rev-parse --abbrev-ref HEAD。四个类似的操作，四套完全不同的语法。

最臭名昭著的例子是 git checkout。这一个命令至少承担了五种完全不同的职责。下面这张思维导图直观地展示了 checkout 到底有多「万能」：

git checkout 五种含义

Git 2.23（2019 年 8 月）终于把它拆分成了 git switch 和 git restore，但 checkout 并没有被废弃，新旧命令共存，六年过去了大量教程和开发者还在用 checkout。

还有 git reset，它的 --soft、--mixed、--hard 三个参数对三棵「树」做完全不同的操作。.. 和 ... 在 git log 和 git diff 里含义恰好相反。merge 和 rebase 操作中「ours」和「theirs」的含义是互换的。

Junio Hamano 自己解释过这是怎么发生的：「这个系统并不是被设计出来的，而是有机生长的。有人想到一个点子……『那就把它作为这个选项名加到这个命令里吧。』然后这个选项名就永远留下来了。」

▶ 内核文化塑造了 Git 的性格

Git 的「高级用户优先」设计哲学直接反映了 Linux 内核的开发文化。内核社区有上千名活跃贡献者，每周通过层级化的 lieutenant 系统提交数千个 patch。这不是五个人用 GitHub Flow 开发一个 Web 应用的场景。Git 假设用户理解 DAG、手动解决冲突是家常便饭、改写历史是正常工作流，这些假设对内核开发者完全合理，对其他所有人则相当吓人。

BitKeeper 的创始人 Larry McVoy 说过一句很尖锐的话：「Linus 跟我承认过这是个糟糕的设计。它做了他想要的事，但他想要的不是世界应该想要的。」Linus 自己也在 Google Talk 上承认，「早期版本的 Git 确实需要一定的脑力才能理解」。

MIT 的研究者 Santiago Perez De Rosso 和 Daniel Jackson 在 2013 年发表了目前最严谨的学术批评，论文标题直接叫 "What's Wrong with Git?"。他们的核心论点是：Git 的复杂性「可能不是其强大功能的必然代价，而是设计缺陷的证据」。他们识别出了具体的概念过载和不一致之处，并基于此开发了 Gitless，一个消除了暂存区、让分支真正独立的 Git 实验性包装器。

中文技术社区对这个问题的认知倒是相当清醒。知乎上关于 Git 缺点的讨论中，最精辟的观点区分了两个层面：Git 的内部架构是优雅的，Git 的用户界面是混乱的。 多位中文技术作者推荐自底向上的学习路径，先理解数据模型再学命令，因为「一旦搞懂了 Git 的数据模型，再学习它的接口就非常容易了」。这其实暗合了 Linus 最初的设计意图：他造的本来就是数据模型层，界面层本该由别人来好好设计。

▶ 新一代工具在修什么

最有前途的改进方案不是替换 Git，而是包裹它。

Jujutsu（jj） 由 Google 工程师 Martin von Zweigbergk 开发，用 Git 仓库做存储后端，但重新设计了用户体验。它最核心的简化有三个：彻底去掉暂存区（工作副本本身就是一个 commit），引入 change ID（在 amend 和 rebase 后保持不变，不像 Git 的哈希会变），以及把合并冲突当作可以被 commit 的结构化数据来处理。目前 Google 内部已经在用，是对 Git 界面层最深思熟虑的一次重新设计。

Sapling 是 Meta 在 2022 年开源的，内部用了超过 10 年。同样 Git 兼容、没有暂存区、不强制要求分支名、amend 早期 commit 时自动 restack 后续 commit，还有一等公民级别的 undo。它的 Interactive Smartlog 提供了 git log --graph 远远达不到的可视化效果。

GitHub 对 Git 普及的贡献可能比任何技术改进都大。2008 年成立后，GitHub 用 Pull Request、Web 编辑器和 fork-and-PR 工作流把 Git 的复杂性抽象掉了，让从未碰过 git rebase 的开发者也能参与开源贡献。GitHub Flow 把 Git 无限的灵活性收窄成一个可管理的模式：main 保持可部署，建 feature branch，开 PR，review 后 merge。GUI 工具如 GitKraken、Sourcetree、VS Code 内置 Git 进一步降低了门槛。

Git 自身也在缓慢改进。git switch 和 git restore（2.23，2019）拆分了 checkout。新的 ort merge 策略（2.33+）更快更准确。微软的 Scalar 项目已经合入 Git 主线，能处理 Windows 代码库那种 350 万文件规模的仓库。但这些都是增量改进，Git 的命令界面考古层纹丝未动，每个旧命令都为了向后兼容而保留着。

▶ 回到问题本身

Git 的复杂不是单一设计缺陷造成的，而是一个历史地质层。最底层是分布式版本控制本身的固有复杂度，任何工具都消除不了。往上是内容寻址存储和 DAG 模型，优雅但需要真正的概念理解。再往上是暂存区，强大的功能但增加了一整个状态维度。最顶层是有机生长、从未被系统性设计过的命令界面。

理解 Git 复杂性的最重要洞见是：Git 的内部模型远比它的界面暗示的要简单。 总共就四种对象类型（blob、tree、commit、tag）和一堆引用指针。DAG 一旦理解了，几乎能解释所有操作。自底向上学，先搞懂数据模型再学命令，是穿越复杂性的最可靠路径。

所以「为何 Git 搞那么复杂」的真正答案是：Git 是一个内核开发者在许可证危机中用十天造出来的文件系统工具包，然后全世界都拿来当用户应用了。 每一层复杂都有原因，但不是每个原因都必须产生那么多复杂。20 岁了，没有竞争对手，Git 的复杂性已经成了整个软件行业呼吸的空气。