本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
10 天写出来的 Git，1000+ 命令是怎么变臃肿的？
最近我看到了一个话题，说 Git 越来越复杂了。常用的命令 20 个不到，实际上的命令超出你的想象。
git 20 年了，现在它管理的代码 41% 由 AI 生成。git 也复杂到臃肿的不行了，以至于 Google 亲自资助 Jujutsu，试图终结 Git 的统治。
实际情况如何，众说纷纭。今天，我就抽点实际，整理一下从 RCS 到 Git 再到 Jujutsu，版本控制工具这二十年的演进与“复杂性之辩”。
文章配图参见我的公众号文章 https://mp.weixin.qq.com/s/VFMLDdLqR0u_I_4SJocWtQ。
一个被十天神话掩盖的真相
2026 年 4 月，Git 迎来了它的 21 岁生日。这个由 Linus Torvalds 在“10 天之内”写出的工具，如今已成为软件开发世界的基石。但鲜为人知的是，Linus 在 20 周年（2025）访谈中澄清：“那 10 天只是编码时间，Git 的构思实际用了 4 个月”。
从这里可以看出，国内的很多软件、系统都设计的非常草率，然后各类牛马靠 996 等形式挤出更多的时间来试错、填坑等。这里不细表了，说多了都是泪。
现如今，Git 是如此流行，超出了所有人的想象。要知道 Git 的诞生并非为了“改变世界”，而是为了解决一个极其具体的问题。即 Linux 内核开发团队失去了 BitKeeper 的免费使用权，Linus 需要一个能让自己“在半分钟内应用 50-100 个补丁”的工具。
这个初衷，决定了 Git 的基因，也埋下了关于“复杂性”的永恒争议。
中心化时代
在中心化时代，是从 RCS 到 SVN 的“单点困境”。
本地版本控制 RCS
1982 年，普渡大学的Walter F. Tichy发布了 RCS（Revision Control System）。这是版本控制的“石器时代”，采用“反向差异”存储，只保存版本间的差异以节省空间。
RCS 的核心局限在于：“它只为单人设计”。在 RCS 的世界里，没有“协作”这个概念，只有“本地备份”。
集中式版本控制
集中式版本控制工具，是 CVS 与 SVN 的双子星局面。
1986 诞生的 CVS 首次解决了多人协作问题，但也留下了诸多痛点，如下所列。
- 仅支持单文件追踪，缺乏原子提交
- 分支管理孱弱，合并简直是噩梦
- 对二进制文件支持繁琐
之后，时间来到 2000 年，SVN 作为“更好的 CVS”登场了，它带来了革命性改进。
- 原子提交：确保多文件修改要么全部成功，要么完全回滚
- 三路合并：相比 CVS 的二路合并，大幅降低了冲突概率
- 引入标签（Tag）机制，重新设计了分支逻辑
但 SVN 也并非完美的版本管理工具，它无法解决的一个根本问题是“单点故障”。中央服务器一旦宕机，整个团队停摆；服务器数据丢失，历史记录灰飞烟灭。
分布式革命
分布式版本管理工具的代表就是 Git。下面我们来看看 Git 的诞生与“简单设计”的悖论。
BitKeeper 事件
2002 年，Linux 内核项目开始使用商业软件 BitKeeper。这是当时最先进的分布式版本控制系统，BitMover 公司免费授权给开源社区使用。
2005 年，Samba 开发者 Andrew Tridgell 试图逆向工程 BitKeeper 协议，BitMover 公司震怒，收回了 Linux 社区的免费使用权。就是这场改变历史的“收回授权”诞生了 Git。
Linus 的选择是：“道歉是不可能的，这辈子都不可能的”。他决定自己动手。
这里得感谢 BitKeeper、Andrew Tridgell、Linus 等，要不是他们，Git 就没法诞生。
Git 的设计哲学
Git 的设计哲学是 Unix 精神的延续。
Linus 为 Git 设定了五个核心目标。
- 速度：能在半分钟内应用大量补丁
- 简单的设计
- 强力支持非线性开发（允许成千上万个并行分支）
- 完全分布式
- 高效管理超大规模项目
这些目标背后，是深刻的 Unix 哲学，一切皆对象、每个命令只做一件事、提供机制而非策略。
Git 的底层设计极其简洁，采用“快照（Snapshot）而非增量（Delta）”存储，使用 SHA-1 哈希确保数据完整性，将分支视为“指向提交的轻量级指针”。
但问题在于，Linus 只为自己开发。
简单设计为何变得复杂？
Git 的首个版本只有约一万行代码，甚至可以一口气读完。但它只有“管道（plumbing）”，没有“瓷具（porcelain）”。你需要手动运行 commit-tree 命令，手动将 SHA-1 哈希写入 head 文件。
复杂性是层层堆叠的地质沉积，是各类需求的演变。
- 2005 – 2008：Junio Hamano 接管维护，添加用户友好命令
- 2008年：GitHub 上线，推动 Git 普及，但也引入了 Pull Request 等工作流复杂性
- 2010 年代：企业大规模采用，Git LFS、子模块等扩展不断叠加
- 2020 年代：Monorepo、大规模协作、安全合规需求爆发
正如知乎用户 chouheiwa 所言：Git 的复杂不是设计失误，而是 20 年历史层层堆叠的地质沉积。每一层复杂都有它的道理，但这些道理叠在一起，就成了新手的噩梦。
后 Git 时代
后 Git 时代是“简化”与“智能化”的双轨革命。
Git 的臃肿之辩
SQLite 是最大的叛逆。SQLite 作者 Richard Hipp 坚持使用自研的 Fossil 而非 Git，他的批评一针见血。
Git 的思维模型过于复杂。用户需要同时牢记下面的各类概念。
- 工作目录（Working directory）
- 暂存区（Index/Staging area）
- 本地 HEAD
- 本地副本的远程 HEAD
- 实际远程 HEAD
虽然 Git 提供了很多命令和选项在所有这些位置之间进行文件移动和比较，但这分散了人们对正在开发软件的注意力。
新一代工具
新一代工具的代表是 Jujutsu 与 Pijul。
其中 Jujutsu（jj）是 Google 资助的 Git 兼容替代品。
它的核心创新如下所示。
- 工作副本即提交：消除暂存区概念，修改文件后无需
git add - 自动重基与变更追踪：修改历史提交后，后续变更自动 rebase
- 元版本控制：操作日志完整记录，支持任意步骤回滚（
jj undo）
然后 Pijul 是基于数学理论的“完美 DVCS”。
它采用冲突无感知合并（Conflict-free Replicated Data Type）理论，从根本上解决了合并冲突问题。与 Darcs 类似，但解决了其指数时间冲突解决的缺陷。
AI 时代的版本控制趋势
现在是 AI 时代了，回顾 2024 – 2025 年，版本控制工具呈现三大趋势。
- AI 辅助版本控制：自动识别关键变动，建议最佳合并方案
- 跨功能集成：版本控制与任务管理、团队沟通、CI/CD 深度整合
- 语义版本控制：不仅记录“改了什么”，更理解“改动的影响”，自动识别重构、预测冲突概率
复杂性背后的历史逻辑
为什么版本管理工具越来越复杂？
针对这个问题，社区网友总结了 3 条，供我们参考。
第一，问题域本身的扩张。从“保存历史”到“支持千人协作”，从“文本代码”到“二进制资产”，从“单一仓库”到“Monorepo”，需求呈指数级增长。
第二，工作流的多元化。Git 的分布式设计支持“任意工作流”，集中式、功能分支、GitFlow、Forking、Trunk-based … 每种工作流都需要特定命令支持。
第三，生态系统的累积。Git 的成功创造了庞大的工具链（GitHub、GitLab、CI/CD 系统），向后兼容性要求使得“简化”变得极其困难。
Git 的架构真的臃肿吗？
- 从底层看：Git 的核心极其简洁。对象数据库（blob、tree、commit、tag）+ 引用机制，构成了一个优雅的“内容寻址文件系统”。
- 从用户界面看：Git 确实复杂。但正如 Linus 所言：
复杂性在于细节、用户界面以及它必须能够做的所有事情，因为每个人都希望它做不同的事情。 - 关键洞察：Git 的“臃肿”不是技术债务，而是“成功的代价”，它必须兼容 20 年来积累的所有使用场景。
最后
版本控制工具的演进史，是一部“简化”与“能力”的永恒博弈。
- RCS 极简，但无法协作
- SVN 解决了协作，但引入单点故障
- Git 解决了单点故障，但带来了复杂性
- Jujutsu 试图简化 Git，但尚未撼动其生态地位
Git 的真正伟大之处，或许不在于它的“简单”或“复杂”，而在于它的“设计前瞻性”。
2005 年设计的分布式架构，在 2025 年的 AI 编程时代依然适用；当初为 Linux 内核设计的性能目标，支撑起了今天的 Monorepo 巨型代码库。
正如 Linus 所言，我会做一些对我有用的东西，不关心其他人。这种“极致的务实”，反而创造了最具普适性的工具。
同时，不少知名老外大佬给开发者的建议是：
- 新手：不要试图理解 Git 的全部，掌握 20% 的核心命令（add、commit、push、pull、branch、merge）即可应对 80% 的场景
- 资深开发者：尝试 Jujutsu 或 Sapling，体验“工作副本即提交”的流畅感
- 团队 Leader：关注 AI 集成趋势，版本控制正在从“代码仓库”进化为“协作智能中枢”
版本控制工具的未来，不是取代 Git，而是在 Git 的基础上构建更智能的抽象层。毕竟，在这个 AI 生成代码占比已达 41% 的时代，我们需要的不仅是“管理版本”，更是“理解变更”。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Git 诞生 21 周年，1000+ 命令的它是如何变臃肿的？