夜雨聆风
AI 编程时代,我写代码最离不开的工具,居然是个21岁的老东西
回想自从2025年全面拥抱 AI 编程之后，我在 IDE 里干的事就越来越少了。
写代码？AI 写的。补测试？AI 补的。改 bug？你猜——还是 AI。
我现在打开 JetBrains，用得最多的功能就三个：git diff、review、commit。
没了。
真的没了。
我甚至开始怀疑，我到底是个程序员，还是个高级代码审计员。
年初 JetBrains 搞了个大动作，直接梭哈了 Junie + AI 全家桶，推出了 Air 模式，编辑器都快变成 AI 的壳了。
我当时就在想——
照这个趋势走下去，JetBrains 的终局会不会就是：一个超级好用的 Git 客户端 + Diff 可视化工具 + AI 代码审查中心？
你别笑，你仔细想想，是不是这个方向？
代码让 AI 写，人类只负责 review 和拍板。那最核心的工具链是什么？是 Git 啊，同学。
所以今天，我想认认真真聊聊这个我们天天用、但大部分人从来没真正了解过的东西——
Git。
一个2026年了还在统治整个开发世界的、21岁的”老古董”。
一、Git：一个男人被逼急了的产物
先说 Git 是谁写的。
答案你可能知道——Linus Torvalds。对，就是写 Linux 内核的那位大爷。
但你可能不知道的是，他写 Git 的原因特别朋克：被逼的。
2005年，Linux 内核团队一直在用一个叫 BitKeeper 的版本控制工具。这东西是商业软件，但作者好心让开源社区免费用。
结果社区里有个老哥逆向了 BitKeeper 的协议。
人家版权方一怒之下：收回授权，不让用了。
Linus 一看，得，求人不如求己。
然后这哥们花了大概两周，用 C 语言写出了 Git 的第一个版本。
两周。C 语言。一个改变全世界软件开发方式的工具。
你搁这搞黑客松呢？
2005年4月3日开始动手，4月7日就能做版本管理了，4月29日已经在用 Git 管理 Linux 内核代码了。
效率狂魔，不是吹的。
当然了，那个时候的 Git 跟我们现在用的 Git，长得完全不是一个物种，后面会说。
二、Git 的设计哲学：去中心化的偏执狂
Linus 这个人有个特点：他不信任任何人，也不信任任何中心化的东西。
你看 Linux 内核的开发模式就知道了——全球几千号人协作，没有一个”中央服务器”说了算。
所以 Git 的设计哲学，骨子里就是四个字：分布式、快、稳、不信任。
展开说说。
第一，分布式。 每个人本地都有一份完整的仓库，包括全部历史记录。不是”从服务器上签出一个文件”那种，而是”你本地就是一个完整的仓库”。服务器炸了？没事，随便拉一个人的本地仓库就能恢复。这在2005年是相当激进的设计——那时候主流还是 SVN 那种中心化的玩法。
第二，速度。 Linus 写内核的，对性能有洁癖。Git 从第一天起就是按”管理几万个文件、几十万次提交”的规模来设计的。分支切换、日志查看，都是毫秒级。用过 SVN 切分支的老哥应该有体会，那叫一个酸爽。
第三，数据完整性。 Git 里每一个对象都用 SHA-1 做哈希校验。任何一个字节被篡改，哈希值就对不上。你可以理解为——Git 自带了一套”防伪系统”，从根儿上保证历史记录不会被偷偷改掉。
第四，不信任网络、不信任服务器。 几乎所有操作都是本地完成的。断网了？照样 commit、branch、merge、查日志。等有网了再 push。这也是为什么 Git 在飞机上、在地铁上、在你家断网的时候照样能用。
你品品，这套哲学放到2026年，依然先进得离谱。
三、灵魂拷问：插入一行代码，Git 怎么知道是”插入”而不是”后面全改了”？
这个问题我跟你说，我问过好多干了五六年的开发，十个有八个答不上来。
你想啊，一个文件100行，你在第50行插入了一行新代码。
那第51行到第101行，内容不是全都”变了”吗？（原来的第50行变成了第51行，以此类推）
Git 怎么聪明到知道”哦，你只是插了一行，后面的没动”？
答案是：Diff 算法，具体来说是 Myers Diff 算法。
这玩意是 Eugene Myers 在1986年发表的论文里提出的，核心思路是：找两个文本之间的最长公共子序列（LCS），然后把不在公共子序列里的部分标记为新增或删除。
听着学术？我打个比方。
你有一副扑克牌，按顺序排好了。现在你从中间插入了一张鬼牌。
一个聪明人看一眼就知道：”哦，你就加了张鬼牌，其他牌顺序没变。”
他不会傻到说”从鬼牌往后的每张牌都换了位置所以全是修改”。
Myers 算法干的就是这个”聪明人”的活——它会去找出两个版本之间最大的相同部分，然后把差异最小化地呈现出来。
而且它追求的是编辑距离最短的那个 diff 结果。也就是说，在所有可能的”描述差异的方式”里面，它选那个改动最少、最直觉的那个。
所以你看到的 git diff 输出是绿色的一行新增、其他行没动，而不是一大片红红绿绿的”全改了”。
这个算法时间复杂度是 (O(N \cdot D))，其中 N 是文本长度，D 是差异数量。改动越少，越快。完美适配日常开发场景——你一次 commit 通常就改几行到几十行嘛。
顺带一提，Git 后来还引入了 patience diff 和 histogram diff 等变体算法，在某些场景下比原版 Myers 表现更好，特别是处理大段代码移动的时候。你可以通过 git diff --diff-algorithm=patience 来切换，大部分人不知道这个参数，我也是今天刚知道:D。
四、Git 的工作原理：它根本不存”差异”，它存的是”快照”
这个是很多人最大的误解。
大部分人以为 Git 存的是”每次修改了什么”——就像一个记账本，记着”第3行改了””第50行删了”。
不是的。
Git 每次 commit，存的是整个项目在那个时刻的完整快照。
“等等，那不是巨占空间？”
别急。Git 有自己的压缩策略。
Git 内部有四种核心对象：Blob、Tree、Commit、Tag。
Blob 就是文件内容。注意，是”内容”不是”文件名”。两个不同文件如果内容一模一样，Git 只存一份 Blob。
Tree 就是目录结构。它记录了”这个目录下有哪些文件，文件名是啥，对应的 Blob 是哪个”。
Commit 就是一次提交。它指向一个 Tree（这次提交的项目快照），再加上作者、时间、提交信息，还有——指向父 Commit 的指针。
就是这个父指针，把所有 Commit 串成了一条链——也就是你 git log 看到的那条历史线。分支合并的时候一个 Commit 可能有俩父指针，就形成了 DAG（有向无环图）。
Tag 就是给某个 Commit 打个标签，比如 v1.0.0，方便人类识别。
每个对象都用 SHA-1 做哈希值来命名，内容一样哈希就一样，内容不同哈希必然不同。
这套设计精妙在哪呢？
如果你这次 commit 只改了一个文件，那其他没改的文件对应的 Blob 跟上次一模一样，Git 直接复用，不会重复存储。只有改了的那个文件会生成一个新的 Blob。
而且 Git 还有个叫 packfile 的机制——当对象越来越多的时候，Git 会自动把它们打包压缩，这时候才会用到类似”增量存储”的策略。但在逻辑层面，Git 始终是以快照为单位思考的。
这跟 SVN 那种”存差异”的思路完全不同，也是 Git 分支操作如此快的根本原因——切分支就是换个指针，不需要重新应用一堆 diff。
五、Git 的源码开源吗？当然，而且你绝对看得到
Git 本身就是用 Git 管理的（套娃警告），源码完全开源，遵循 GPL v2 协议。
你可以在这两个地方看到：
GitHub 镜像：github.com/git/git
官方仓库：git.kernel.org 上的 pub/scm/git/git.git
代码主要是 C 语言写的，早期版本还夹杂着不少 Shell 脚本和 Perl 脚本。后来社区慢慢把很多脚本实现用 C 重写了，性能更好，跨平台兼容性也更强。
说实话，Git 的源码是学习 C 语言项目工程化的顶级教材。代码风格朴素、注释清晰、模块化做得非常好。如果你想提升 C 语言功力，可以从读 Git 源码开始，比刷 LeetCode 有营养多了。
另外，Git 的官方文档也是一绝。git-scm.com 上有完整的 Book（Pro Git），免费看，中文版都有。从入门到深入原理全覆盖。
六、2005年的 Git vs 2026年的 Git：简直两个物种
最后聊聊，21年过去了，Git 变了多少。
2005年那个 Git，说白了就是 Linus 给自己和内核团队攒的”够用就行”的工具，命令行界面粗糙得很，很多操作得手动拼底层命令。
2026年的 Git（截至写这篇文章，最新稳定版已经是 2.48.x 了），早就今非昔比。
哈希算法升级。 老版本用的 SHA-1，理论上存在碰撞风险（2017年 Google 就实际做出了 SHA-1 碰撞）。现在 Git 已经在逐步过渡到 SHA-256，虽然完整迁移还在进行中，但底层支持已经就位了。
性能优化。 对超大仓库的支持好了太多。微软当年把 Windows 源码搬到 Git 上，搞了个 VFS for Git（后来叫 Scalar），倒逼 Git 社区加入了 partial clone（部分克隆） 和 sparse checkout（稀疏检出） 等特性。你不用把整个几十 GB 的仓库全拉下来，可以只拉你要的那部分。
用户体验提升。git switch、git restore 这些新命令把 git checkout 那个万能但混乱的语义拆分开了。不再是一个 checkout 走天下、新手死在半路上的时代了。
Merge 和 Rebase 更智能。 新的 merge-ort 策略替换了老旧的 merge-recursive，速度更快，冲突处理更合理。
安全性增强。 签名验证、凭证管理、协议安全，全面加强。
钩子和扩展能力。 各种 hook 更完善，加上 Git LFS（大文件支持）的成熟，Git 已经不只是管代码的，管资源文件、管模型文件都行了。
但说到底，最核心的那套东西——Blob/Tree/Commit 的对象模型、有向无环图的历史结构、分布式的设计哲学——从2005年到2026年，没变过。
Linus 两周写出来的那个”地基”，撑了21年，至今还在撑着全世界几亿开发者的日常工作。
你说牛不牛？
人类最后的阵地
2026年了，AI 能写代码、能改 bug、能做 code review、能生成测试用例。
但有一件事 AI 替代不了：决定这段代码要不要合进主分支、要不要发布上线。
而这个”决定”，最终体现在哪？
git merge。git push。
按下回车的那一刻，责任是人的。
所以我说，Git 可能是 AI 时代程序员最后的”阵地”。
你不需要再手写每一行代码，但你得看懂每一行 diff，得对每一次 commit 负责。
这事儿，21年前 Linus 大概没想到。
但他造的这个工具，恰好为这个时代做好了准备。
挺有意思的，不是吗？
我是幽皇，一个2026年还在认真看 diff 的人。（除非 diff 真的太多。。。）
觉得有收获的同学，点个赞再走。下次有机会再聊聊 AI 时代的 Code Review 到底该怎么做——毕竟这可能是我们最后的手艺活了。