Linguista

「人物志-LinusTorvalds」Git 诞生二十周年访谈

内容介绍

本次访谈录记录了在 Git 诞生将近二十周年之际，对其创建者 Linus Torvalds 的一次深度对话。访谈围绕 Git 这款如今在软件开发领域无处不在的版本控制系统展开，内容涵盖了其诞生的历史背景、核心设计理念、早期快速开发过程以及后续的演进。Linus Torvalds 分享了他最初因不满现有工具（如 CVS）并遭遇 BitKeeper 许可危机而决定自行开发 Git 的动机，详细阐述了性能、数据完整性和分布式设计在其理念中的核心地位。对话还探讨了 Git 如何从一个解决个人需求的工具，意外地发展成为行业标准，以及 Linus 本人将维护权移交给 Junio Hamano 的考量。此外，访谈也触及了 Linus 对 Git 当前使用状况的看法、他个人与 Git 的“休闲”关系、对未来挑战（如超大仓库和统一缺陷跟踪）的思考，以及他对软件开发工具演进的个人哲学。对于希望深入了解 Git 起源、设计哲学以及其创造者心路历程的读者，这份访谈录提供了直接而坦诚的第一手视角。

内容纲要

Git 诞生二十周年访谈录纲要
├── 一、Git 诞生 20 周年回顾与 Linus 的看法
│   ├── 对 Git 长期存在和广泛使用的惊讶
│   ├── 最初为解决个人问题而开发
│   ├── 对 SCM 市场粘性的看法
│   └── 早期因难用而受到的抱怨
├── 二、Git 的起源：BitKeeper 事件与开发动机
│   ├── BitKeeper 作为早期工具及其商业性质争议
│   ├── Tridge 逆向工程引发的许可危机
│   ├── 调解失败，失去 BitKeeper 使用权
│   ├── 现有开源 SCM 无法满足需求 (性能、分布式)
│   └── Git 开发前的思考期 (约 4 个月) 与设计目标确立
├── 三、“十天”冲刺：Git 的快速原型开发
│   ├── “十天”的实际含义 (核心可用版本，非全部)
│   ├── 用户空间编程的相对简易性
│   ├── 早期版本非常底层 (Plumbing)，手动操作
│   ├── 合并功能的逐步实现
│   └── 早期版本的不完善与后续修正 (如对象格式)
├── 四、Git 的核心设计哲学与关键决策
│   ├── 从文件系统角度出发，而非传统 SCM
│   ├── 核心关注点 1：性能 (快速补丁应用)
│   ├── 核心关注点 2：数据完整性与稳定性 (SHA-1 的主要目的)
│   ├── 核心理念：底层简单，上层复杂 (类 Unix 哲学)
│   └── 对 SHA-1 迁移的后续反思 (认为有不必要的消耗)
├── 五、早期发展、社区参与与维护权移交
│   ├── 最初面向硬核内核开发者
│   ├── 外部贡献者的快速加入
│   ├── Linus 仅维护约 3-4 个月
│   ├── 将维护权移交给 Junio Hamano 的原因 (品味、兴趣、长期投入)
│   └── 移交后的彻底放手与对 Junio 工作的肯定
├── 六、Git 的广泛普及与深远影响
│   ├── 分布式特性是成功的关键 (本地操作、轻量、易分享)
│   ├── 催生 GitHub 等平台
│   ├── 适用范围广 (从学生项目到大型企业)
│   ├── 用户群体的转变 (从抱怨到接受与默认)
│   └── 对软件开发细节的影响 (协作、小项目)
├── 七、Linus 目前与 Git 的关系
│   ├── Git 很早就满足了其核心需求，兴趣转移回内核
│   ├── 成为 Git 的“休闲用户”，仅使用少数核心命令
│   ├── 坚持命令行，不使用复杂工具或集成
│   └── 仍会关注性能改进等细节，但不再深入追踪日常开发
├── 八、对 Git 未来的看法与挑战
│   ├── 主要挑战来自非预期使用场景 (Monorepo, 大文件)
│   ├── 期待更统一的 Bug 跟踪/问题管理系统
│   ├── Git 因网络效应地位稳固，新 SCM 挑战大
│   └── Linus 本人无兴趣尝试其他 SCM 或发起新项目
└── 九、结语与致谢
    ├── 再次强调开发 Git 的初衷是解决自身问题
    ├── 将 Git 的成功主要归功于 Junio 和社区贡献者
    └── 对个人在 Git 长期发展中贡献的定位 (早期奠基)

Git 诞生二十周年访谈录：与 Linus Torvalds 对话

访谈者： 距离 Git 自托管并完成初始提交已经过去快 20 年了，几乎就在此刻。您曾预料到 20 年后还会坐在这里，仍在使用它并谈论它吗？

Linus Torvalds： 嗯，还在用它，是的。也许没料到还在谈论它。这确实是巨大的惊喜之一，它基本上接管了整个版本控制管理（SCM）世界。因为我最初只是把它看作解决我自己问题的方案。而且，即便是在整整 20 年前的今天，我显然也认为它更优越。说实话，第一个版本相当粗糙，但即便那个版本也比 CVS 强。当然了。但同时，我也看到 CVS 占据市场很多年。我的意思是，后来 SVN 出现了，但它本质上只是换了个外壳的 CVS，对吧。它持续了几十年。所以我想，好吧，这个市场非常“粘滞”。我不能用 CVS，因为我极度痛恨它。所以我得做自己的东西。显然我也不能再用 BitKeeper 了。所以我想，好吧，我就做点对自己有用的，不管别人怎么想。而且，必须承认，这在最初的几个月甚至几年里表现得很明显，人们抱怨它有点难用，不够直观。然后，就像是扳动了一个开关，情况发生了变化。

一、 Git 诞生 20 周年回顾与 Linus 的看法

访谈者： 您提到了 BitKeeper，也许我们可以稍微聊聊这个。众所周知，您大约用了 10 天左右写出了 Git 的初始版本，作为（Linux）内核（版本控制）的替代品。

Linus Torvalds： 是，也不是。实际上，距离我能将它用于内核开发，用的时间比 10 天要少。是的。但公平地说，整个过程其实在前一年的 11 月或 12 月就开始了。嗯哼。所以是 2004 年。

二、 Git 的起源：BitKeeper 事件与开发动机

Linus Torvalds： 当时发生的是，BitKeeper 对我来说一直运作得相当好。它并非完美，但比我尝试过的任何其他东西都领先了好几个光年。但在内核社区，BitKeeper 一直不被社区完全接受，因为它是商业软件。它对开源项目免费使用，因为我认识的 Larry McVoy 非常喜欢开源。对吧。但同时，他也在围绕它建立商业模式，想把 BitKeeper 卖给大公司。但它不是开源软件，却被用于最大型的开源项目之一，这对很多人来说是个症结。当然了。对我来说某种程度上也是。我确实想用开源工具，但同时我非常务实，当时没有任何开源工具能达到哪怕接近够用的水平。所以我有点希望会出现更好的东西。

但后来发生的是，澳大利亚的 Tridge（Andrew Tridgell）基本上逆向工程了 BitKeeper。这并不难，因为 BitKeeper 内部基本上是对 SCCS 的良好封装。SCCS 可以追溯到 60 年代，我的意思是，这东西…而且 SCCS 几乎比 CVS 还要糟糕。但这明确违反了 BitKeeper 的许可规则。BitKeeper 的规定是：你可以用它来做开源项目，但你不能逆向工程它，也不能试图克隆 BitKeeper。这引发了巨大的问题。这些都是私下进行的。我和 Larry 谈，也和 Tridge 通邮件，我们试图找到解决方案，但 Tridge 和 Larry 的立场完全是南辕北辙，根本找不到解决办法。

所以，到我开始写 Git 的时候，我已经思考这个问题四个月了。思考什么对我有效，思考如何做出比 BitKeeper 做得更好，但实现方式又与 BitKeeper 完全不同的东西。因为我不想陷入 Larry 指责我说“嘿，你做了那件你最不该做的事”的境地。对吧。

所以，是的，编写代码的部分也许花了 10 天，直到我开始用 Git 管理内核。但这之前有大量的思考，关于核心理念应该是什么。

三、 “十天”冲刺：Git 的快速原型开发

访谈者： 我想谈谈这两方面。我们可以先从那 10 天左右的时期开始。据我所知，您当时是暂时从内核工作中抽身，几乎完全专注于 Git。对您来说，只做 Git 而不去想内核，这种转换是怎样的体验？

Linus Torvalds： 因为只有两周时间，最终就是那样了。实际上算不上什么大事。过去 35 年里，我也做过类似的事，比如休过几次假，对吧。次数不多，但我确实有过离开内核几周的情况。

而且这还挺有趣的，我的一个反应是，在用户空间编程是多么容易啊！对吧。需要操心的事情少得多。你不用担心内存分配，不用担心很多事情，而且当你拥有所有这些你正在编写的基础设施时，调试也容易得多。绝对如此。所以，做一些用户空间的事情，目标相当明确（明确的是方向，细节还不确定），实际上挺…我不会说放松，但挺有趣的。

说实话，在第一周之后，我有了一个适合应用补丁的东西，但对于其他功能还不太行。我已经有了做合并（merge）的基础数据结构，但实际上好像又过了一周我才做了第一次合并。对吧。有很多事情我并不确定…我脑中有大概的最终目标，但不确定是否能达到。是的。最初的步骤…我的意思是，头一两周，你可以去看看代码，也有人看过了，那代码并不复杂。不，我觉得第一个版本大概是 10000 行代码或者类似规模，你基本上可以一口气读完。是的，而且它非常直接，没做多少错误检查之类的事情。它真的是“让我们把它跑起来”，因为我还有另一个我认为更重要的项目（内核）等着我回去做。

它确实是…我会遇到问题，需要我做些改动。第一个版本，你可以看出来…我想我们后来在某个时候做了一次向后不兼容的对象存储格式转换。至少 fsck 会对一些旧对象报怨。因为我改了数据格式。所以有些地方第一个版本并没有做到它需要做的一切。是的。我忘了我是否真的做了转换，也许根本没必要转换。是的。然后我们只是在内核历史中有几个警告，或者说几个对象，fsck 会说“嘿，这是一个旧的不支持的格式”之类的。

但总的来说，它确实出乎意料地好用。是的。

最初几周，当我用它来管理内核时，我确实是手动使用现在所谓的底层命令（plumbing commands）。没有所谓的上层接口（porcelain），没有任何让它更易用的东西。所以，要创建一个提交（commit），你得做这些非常晦涩的操作，commit-tree，是的，commit-tree write，然后它只返回一个像 SHA-1 哈希值，你手动把它写进 HEAD 文件里，就这样。

访谈者： hash-object 在第一个版本就存在了吗？

Linus Torvalds： 我想那是我最早拥有的几个二进制文件之一，我可以…是的，可以检查我是否能手动哈希所有东西，然后它会把哈希值输出到标准输出，然后你就可以用它做任何你想做的事。但早期的 porcelain 就是我围绕这些非常难用的底层命令编写的 Shell 脚本。而且老实说，即使有了我的 Shell 脚本，它也不容易使用。

访谈者： 合并（merging）功能是在早期就有的，但您提到可能到第二周或第三周才真正可用。还有哪些您在初始版本中省略，但后来意识到对项目至关重要的特性？

Linus Torvalds： 与其说是后来意识到，不如说是我当时不关心，但我知道如果这个项目要发展下去，别人会关心的。

四、 Git 的核心设计哲学与关键决策

访谈者： 这正是我想谈的另一件事。我觉得 Git 特别有趣的一点是，尤其是 20 年后的今天，它所鼓励的开发模型对我来说似乎如此简单，以至于现在几乎是显而易见的。但我这么说并非贬低，我认为从源码控制思想的宇宙中提炼出最终成为 Git 的东西，一定经过了大量的思考。您能告诉我，当时为了得到我们现在拥有的 Git，您做出了哪些在当时看来并不明显的选择吗？

Linus Torvalds： 您说它现在很明显，我认为在当时并不明显。我认为人们觉得 Git 非常难用的原因之一是，大多数开始使用 Git 的人都有类似 CVS 的背景。而 Git 的思维方式…我是从一个文件系统人的角度来看待它的，对吧。我对大多数源码控制管理项目怀有鄙视甚至近乎憎恨。是的。所以我完全没兴趣维持现状。

对我来说，最大的问题是…嗯，有两个巨大的问题。一个是性能，当然了。那时候我还应用大量的补丁，虽然 Git 几乎让这种方式消失了，因为现在我只合并（merge）别人的代码。但对我来说，目标之一就是我能在大约半分钟内应用一个补丁系列，即使它包含 50 到 100 个补丁。你不应该需要去冲杯咖啡。对，正是如此。这对我来说很重要，因为它实际上关乎生活质量。就是那种，如果事情是即时完成的，一旦发生错误，你立刻就能看到结果，然后你就继续前进并修复它。而我曾看过的一些其他项目，每个补丁都要花半分钟，这对我来说是不可接受的。是的。那是因为内核是个相当大的项目，而很多这类 SCM 根本就没设计成可扩展的。是的。

所以这是一个问题。另一个问题确实是，我知道我需要它是分布式的，但我需要它非常非常稳定。 嗯哼。人们有点认为使用 SHA-1 哈希是个巨大的错误。但对我来说，SHA-1 哈希从来不是关于安全性的。它是关于发现数据损坏的。当然了。因为我们在 BitKeeper 时期确实遇到过一些这种情况。BitKeeper 使用了 CRC 和 MD5，对吧，但没有用在所有地方。对吧。所以我早期的设计之一就是，绝对所有东西都由一个非常好的哈希来保护。当然了。

这在某种程度上驱动了整个项目。有两三个非常基本的设计思想，这就是为什么 Git 在底层实际上相当简单。然后复杂性在于细节、用户界面以及它必须能够做的所有事情，因为每个人都希望它能做些疯狂的事情。但是，拥有一个基于少数核心概念的底层设计，使得编写更容易，思考更容易，某种程度上也更容易向人们解释其理念。

我有点把它比作 Unix。Unix 有一个核心哲学：一切皆进程，一切皆文件，你通过管道连接事物。然后现实是，它其实并不简单。我的意思是，哲学背后有简单的概念，但所有细节都非常复杂。我想这就是当初让我欣赏 Unix 的原因。是的。我认为 Git 也有类似的特点，设计中存在一种根本的核心简洁性，然后是实现的巨大复杂性。是的，从 Unix 到 Git 的设计方式有一条贯穿始终的线索。

访谈者： 您提到了 SHA-1。在您开发 Git 第一个版本的那一两周里，我思考的一件事是，您做了很多至今仍在影响我们的决定。是的。有没有哪些决定，包括或不包括 SHA-1，是您后悔或希望当初做得不同的？

Linus Torvalds： 嗯，SHA-1 我后悔，是因为我觉得它在试图同时支持 SHA-256 和 SHA-1 的整个过程中造成了很多无谓的折腾。我理解为什么会这样，但我确实认为这在很大程度上是没必要的。我不认为有巨大的实际需求，但人们很担心，所以就这么做了。所以我认为那里浪费了很多精力。

还有一些其他的小问题。我认为我在索引文件条目（index file entries）的排序方式上犯了个错误。我觉得存在这些愚蠢的细节，让事情变得比应有的更困难。是的。但同时，其中许多事情是可以修复的，但它们足够小，所以并不真的重要。对吧。所有的复杂性都在别处。是的。是的。是的。

五、 早期发展、社区参与与维护权移交

Linus Torvalds： 公平地说，这个项目的第一个目标受众是相当硬核的内核开发者，他们之前一直在用 BitKeeper。所以他们至少了解我所追求的很多概念。嗯哼。而且人们接受了它。我的意思是，我认为没过多久，就有其他内核开发者开始真正使用它了。而且我实际上很惊讶，一些源码控制领域的专家也很快加入进来。在我发布第一个 Git 版本后的几天内，我就开始收到来自外部的补丁。

访谈者： 我们聊了很多关于 Git 最初几周的事情。我想往前推进一点。您在项目早期就决定将维护权交给 Junio（Hamano）。我想知道您能否谈谈，这么多年来，在保持一定距离的情况下，看着他管理项目，看着社区与之互动，是种什么样的体验？

Linus Torvalds： 说实话，我大概维护了 Git 三四个月。我想我是在八月份左右交接的。当我交接时，我真的是彻底放手了。我当时想，我还在，我还在阅读 Git 邮件列表（我现在不读了）。Junio 想确保如果他问我任何事情，我都会在。但同时，我也觉得，这不是我想做的事情。

我仍然觉得有点傻。我大女儿上大学两个月后，给我发了条短信说，在计算机科学实验室里，我因为 Git 比因为 Linux 更出名，因为他们那里所有事情都用 Git。我当时想，Git 对我来说从来都不是什么大事。它只是“我需要完成这个才能做内核”的事情。当然了。这有点荒谬，是的，我用了生命中的四个月来维护它。但现在，20 年后，是的，你绝对应该和 Junio 谈，而不是和我谈，因为他做得非常出色。我很高兴事情发展得这么好。

但说实话，我会把功劳归于我在互联网上与人合作足够长时间，以至于在那四个月的维护期间，我很擅长识别出谁有“好的品味”（good taste）。是的。成为一个好的维护者。

访谈者： 对您来说，关键在于品味？

Linus Torvalds： 对我来说，这很难描述，但…是的。你必须…你可以看出来。你可以在补丁中看到，在他们对别人代码的反应中看到，在他们思考问题的方式中看到。他不是项目中的第一个人，但他是早期的人之一，从我公开项目后差不多第一周就在那里。所以他是早期的人之一。但这并不是说“你是第一个，标记一下，就是你了”。更像是，“好吧，我已经观察这个人工作三个月了，我不想维护这个项目。我会问他是否愿意成为那个维护者。” 我想他一开始有点紧张，但它确实一直运作得很好。

访谈者： 他确实非常出色地管理着项目。

Linus Torvalds： 是的。我的意思是，所以“品味”对我来说非常重要，但实际来说，你在一个项目上坚持 20 年，这才是更重要的部分，对吧。他做到了。是的。我的意思是，他对树（代码库）中几乎所有领域都了如指掌，达到了令人惊讶的程度。是的。

六、 Git 的广泛普及与深远影响

访谈者： 好的，我们聊了很多关于早期 Git 的事情。我想谈谈 Git 的中期阶段。关于这个工具，我发现特别有趣的一件事是，鉴于它变得如此无处不在，它显然有效地帮助了内核的开发。是的。但它对于在笔记本电脑上写小型课程项目的大学生来说也非常有效。您认为 Git 有什么独特之处，使其在软件工程谱系的两端都如此有效？

Linus Torvalds： 分布式的特性最终使得很多事情变得如此容易。这是 Git 与之前几乎所有 SCM 区别开来的一个重要部分。是的。我的意思是，以前也有分布式的 SCM，但据我所知，从来没有哪个像 Git 这样，将其作为首要设计目标之一。我的意思是，与其他首要设计目标一起。

你可以完全在本地使用 Git。然后，如果你想把它放到其他任何地方，是如此容易。这与比如说 CVS 非常不同，使用 CVS 时，你必须先建立一个中心化的仓库。如果你想把它移到别处，那简直痛苦不堪。而且你无法在不失控的情况下与别人分享，或者说，使用传统 SCM 时，总会有一个特殊的仓库。而 Git 没有这样做，并且在设计上就刻意不这样做，这使得像 GitHub 这样的服务变得轻而易举。我的意思是，我可能把 GitHub 说得太简单了，因为我知道在 Git 周围构建所有基础设施需要大量工作，但同时，基本的 Git 托管方面几乎是“无”。因为 Git 的整个设计就是为了便于复制。而且每个仓库都是相同和平等的。我认为这最终使得它对于个人开发者来说如此易用。当你创建一个新的 Git 仓库时，没什么大不了的。就像你执行 git init，就完成了。你不需要设置任何基础设施，也不需要做任何传统 SCM 需要做的那些事情。然后，如果那个项目发展到某个阶段，你决定“哦，也许我想让其他人也参与进来”，那也行。同样，你不需要为此做任何事。你只需把它推送到 GitHub，又完成了。是的。这是我非常想要的东西。

而且我没意识到还有那么多人也想要。我以为人们对 CVS 和 SVN 挺满意的。对吧。嗯，我其实不那么认为，但我以为它们对大多数人来说已经足够了，所以会保持现状。

访谈者： 我们刚才稍微谈到了 Git 如何在软件工程的两极都有适用性。我的整个职业生涯都伴随着版本控制作为软件开发的一部分。我很好奇的一点是，您如何看待 Git 在塑造当今软件开发方式方面的作用？

Linus Torvalds： 这对我来说是个太大的问题了。我不知道。这不是我写 Git 的原因。我是为了解决我自己的问题而写的。嗯。

我认为 GitHub 和其他托管服务已经清楚地表明，现在创建所有这些随机的小项目是多么容易，这在过去是做不到的。是的。这也导致了很多死项目。比如你会发现这些一次性的东西，有人做了点什么然后就扔在那里了，它还在那里。但这真的从宏观上改变了软件开发的方式吗？我不知道。我的意思是，它改变了细节。它在某种程度上让协作更容易，让做这些一次性项目更容易，如果项目不行就算了，如果行，现在你可以和别人一起工作了。但是，我不确定它是否从根本上改变了软件开发的任何东西。

访谈者： 您之前提到，当人们开始欣赏 Git 的能力而不是抱怨它有多么不同时，那对您来说是件大事。那大概是在 Git 诞生几年之后。

Linus Torvalds： 是的。我想是那些奇怪的 Web 开发者开始大量使用 Git。好像是 Ruby on Rails 社区。我的意思是，我对此一无所知，我现在仍然不知道 Ruby 是什么。对吧。但是 Ruby 和 Rails 的人在 2008 年左右的某个时候开始使用 Git，类似这个时间点。对吧。这很奇怪，因为它带来了一种全新的 Git 用户，至少是我以前从未见过的。对吧。而且它肯定是在后台存在的，只是这让事情变得非常明显，突然间你有了所有这些年轻人，他们以前从未用过 SCM，Git 是他们接触的第一个东西，而且他们正在使用的项目就在用 Git，所以它成了默认选项。是的。我认为这改变了动态。当你不再有那些用了一辈子截然不同的 SCM 的老家伙，而是突然有了从未见过其他东西的年轻人，他们欣赏它，而不是说它有多难。我开始看到这些人抱怨“当这个旧项目在 CVS 里时，我该怎么做这个？”对吧。所以那很有趣。是的。

人们开始欣赏……我的意思是，远超我的想象。是的。尤其是考虑到最初几年，我因为 Git 的界面收到了很多仇恨言论。哦，抱怨声不断。

访谈者： 跟我说说吧。

Linus Torvalds： 哦，我的意思是，更像是……我无法具体指出。你得去 Google 一下。但有多少人给我发邮件问“为什么它要这么做？”呃，还有关于我选择的名称引发的口水战。例如，我没有 git status 这个命令，这实际上是我相当常用的命令之一。它可能不在前五，但仍然是相当常用的。我想我在用 CVS 时从未用过它，因为它太慢了。人们有各种各样的期望。所以我只记得最初几年，关于为什么子命令的名称无缘无故地不同而产生的抱怨。主要原因是我就是不太喜欢 CVS，所以我有时故意做得不一样。

然后，转变确实发生了，大概在 2007 年到 2010 年之间。是的。是的。当人们从抱怨 Git 多么难用，转变为真正欣赏 Git 的某些强大之处时，这对我来说很有趣。当然了。

七、 Linus 目前与 Git 的关系

访谈者： 您之前提到，您可能不是很快，但至少有一段时间没有定期关注邮件列表了。是的。事实上，距离您上一次向项目提交代码也有一段时间了。我数了一下，好像是 2022 年 8 月是最后一次提交。

Linus Torvalds： 是的。我我的代码树里有一些实验性的补丁，我只是留着它们。所以这些天，我会拉取 Git 的源码，然后我有大概四五个我自己使用的补丁。我想我把其中一两个发到了 Git 邮件列表，但它们不是很重要。它们像是细节问题，而且往往与我的工作流非常具体相关。

但说实话，我的意思是，这对于 Linux 内核也是如此。我做 Linux 已经 35 年了，它在我需要的所有方面，第一年就做到了。对吧。而让我在内核方面坚持下去的是：a) 硬件不断发展，内核当然需要随之进化；b) 是所有其他人的需求，我这辈子永远不会需要内核所做的所有功能。是的。但我对内核感兴趣，35 年后我还在做这个。

但对于 Git 来说，它在我需要的功能方面，第一年内就做到了。事实上，主要是在最初几个月内。是的。当它满足了我的需求后，我就失去了兴趣。因为…当涉及到内核时，我真的对它们如何工作很感兴趣，这是我做的事情。但当涉及到 SCM 时，就好像…是的，我一点也不感兴趣。

访谈者： 在过去几年里，项目中有没有什么您关注过并且觉得有趣的特性？

Linus Torvalds： 我喜欢合并策略（merge strategies）变得稍微聪明了一些。是的。我喜欢一些脚本最终用 C 重写了，只是为了让它们更快。是的。因为我发现，即使我现在不再应用像 100 个补丁那样的系列了，但我最终还是会做像为测试树（test trees）做 rebase 之类的事情。所以拥有一些性能改进…但话说回来，我的意思是，这些最终都是相当小的实现细节。它们不是那种大的变化。我的意思是，我认为几年前我还在追踪的最大变化是所有关于多哈希（multiple hashes）的事情，那对我来说看起来非常痛苦。

访谈者： 在生态系统中，有没有什么您用过的与 Git 配套的工具？我是 TIG 的忠实用户，不知道您…

Linus Torvalds： 我从来没用过。不。即使在早期，当 Git 真的很难用，并且有那些附加的 UI 时…我唯一用过的 Git 包装器是 gitk。是的。而且那很明显很快就被集成到 Git 中了。是的。相当快。对吧。但我仍然完全使用命令行。我不使用任何编辑器集成的东西。我什么都不用，因为我的编辑器太笨了，无法与任何东西集成。它远不如 Git 好。

所以我偶尔会对我的 Git 历史使用情况做些统计，只是因为我想知道“我用哪些命令？”是的。结果发现我只用五个 Git 命令。而 git merge、git blame 和 git log 是其中的三个。好的。非常如此。从这个意义上说，我是 Git 的一个非常休闲的用户。

访谈者： 我必须问问另外两个是什么。

Linus Torvalds： 嗯，显然是 git commit 和 git pull。我在某个时候做了这个“前五名”统计，可能已经变了，但是…就像，并不多。我确实有一些脚本，然后会用 git rev-list 深入底层，为项目做统计，但就我与项目的交互而言…是的。是的。

访谈者： 您觉得项目中有哪些特性，无论是早期还是后来的，可能没有得到它们应有的赏识？

Linus Torvalds： 哦，我的意思是，它得到的赏识已经远超它应得的了，所以…是的。这和我被问到的正好相反。

八、 对 Git 未来的看法与挑战

访谈者： 我们来展望一下。现代软件开发的变化速度前所未有的快。

访谈者： 您要说 AI 这个词了吗？

Linus Torvalds： 我不会说 AI 这个词，除非您想说。

访谈者： 不，不。您认为工具的哪些方面已经进化，或者可能仍需进化，以继续支持人们正在使用的那些新的、要求更高的工作流？

Linus Torvalds： 我很想看到更多缺陷跟踪（bug tracking）方面的东西。我的意思是，每个人都在做这个。我的意思是，无论你称之为缺陷跟踪还是问题（issues）或者随便你怎么叫，它们都是…我希望看到它能更加统一。因为现在它非常 fragmented（碎片化），每个托管网站都做自己的版本。我理解他们为什么这样做。A) 没有一个标准的、好的基础；B) 这也是一种提供附加值并将人们留在那个生态系统中的方式，当然了，即使 Git 本身意味着迁移代码非常容易。但我确实希望有一个更统一的东西，缺陷跟踪和普遍意义上的问题能够成为托管网站之间更共享的东西。当然了。对。

访谈者： 我们来思考一下项目的未来。我想也许可以先从您认为 Git 正在面临或将要面临的最大挑战开始。

Linus Torvalds： 我甚至不知道。我的意思是，它取得的成功远超我的…我的意思是，统计数据是惊人的。它从只用于内核和几个其他项目，到变得相当流行，再到现在占据了大概 98% 的 SCM 使用率。我的意思是，这是我去年在某个报告中看到的数字。所以我的意思是，我不知道这有多准确，但它占比巨大。是的。

从这个意义上说，我不会担心挑战，因为我认为 SCM 存在非常强的网络效应。这可能就是为什么它一旦起飞就势不可挡的原因。就是当其他所有项目默认都在使用 Git 时，所有新项目也会使用 Git。因为在两个不同的项目上使用两种不同的 SCM 所带来的痛苦实在不值得。所以我认为这对 Git 来说不算挑战，反而对任何认为自己有更好东西的人来说是个挑战。

而且说实话，因为 Git 做了我需要的所有事情，挑战很可能来自新的使用方式。我的意思是，我们已经看到了一些。我们看到一些人用 Git 的方式，正是我明确认为错误的方式。是的。比如微软，那个包含所有东西的单一仓库（monorepo），这暴露了可扩展性问题。对吧。我不是说微软这样做是错的。我是说这确实是 Git 当初设计时没有考虑到的。我假设那些问题大多已经解决了，因为我没看到任何抱怨，但同时，我也不像以前那样关注 Git 邮件列表了。我甚至不知道大文件（large file）问题是否被认为解决了。如果你想把一个 DVD 镜像放进 Git 里，那就像是…你为什么会想那么做？但我的意思是，这就是挑战：当 Git 无处不在时，你会发现所有这些人都在做一些你永远无法想象的奇怪事情，那些我没想象到并且认为是完全错误的事情。但是，嘿，我的意思是，那是个人观点。显然其他人有非常不同的个人观点。所以，这总是一个挑战。我的意思是，这我在内核中也看到过，我会想“你到底在干什么？” 对吧。“那不应该能工作，但你显然在这样做。”

访谈者： 在某种程度上，我的意思是…我们谈到，无论是 98% 还是其他统计数字，Git 显然是软件开发中一个巨大的、主导性的组成部分。同时，也有新的版本控制初创公司不断涌现。Pijul、Jujutsu、Piper 等等。我很好奇您是否尝试过其中任何一个？

Linus Torvalds： 不，我没有。我的意思是，说真的，既然我当初进入这个领域就是因为对源码控制完全不感兴趣，那为什么我现在有了对自己有用的东西后，还要去看替代品呢？呃，是的。我确实…我的意思是，我进入这个领域时真的不喜欢源码控制，现在我不再讨厌它了。我认为数据库是…对我来说特别…那是生活中最无聊的事情。但 SCM 仍然…仍然不是我真正感兴趣的东西。

九、 结语与致谢

访谈者： 您给了我最后一个问题的一点线索。按计划，Linux 大约是 34 年前出现的。

Linus Torvalds： 嗯，是的。

访谈者： Git 是 20 年前。

Linus Torvalds： 哦，糟糕的问题。

访谈者： 所以我们可能已经错过了下一个大事件大约五年了？

Linus Torvalds： 不，不。我反过来看。所有我不得不做的项目，我之所以要做，是因为我找不到别人做的更好的东西。但我更喜欢别人为我解决问题。对吧。呃，所以我不得不搞出一个项目，实际上是世界的失败。对吧。而过去 20 年，世界对我来说没有再失败过。对吧。呃，我开始做 Linux 是因为我需要一个操作系统，而没有适合我需求的东西。我开始做 Git 也是同样的原因。我开始做 Subsurface，那是我的潜水日志…嗯，不再是我的潜水软件了，但那个太专业化了，从未大规模流行起来。那解决了一个特定的问题。但是，我的计算机使用实际上非常有限，以至于…我想我已经解决了所有问题了。

部分原因可能是我做这个太久了，我的…就像，我只能用某些方式做事。我还在用我大学时用的那个编辑器，因为我的手指已经学会了一种方式，无法回头了。我知道那个编辑器很烂，我在维护它，因为它是一个死项目，没人用了。所以我有一个源码树，每次安装新机器时我都会编译我自己的版本。我会建议任何人都不要用那个编辑器。但我做不到。我试过。我多次尝试寻找一个更现代、能做些花哨事情，比如给我的源码上色之类的编辑器。每次我尝试，我都会想，“是的，我…这些手对（新东西）来说太老了。”对吧。所以我真的希望不会有项目出现让我觉得“我必须做这个”。是的。

访谈者： 嗯，就此结束吧。感谢您带来 20 年的 Git。

Linus Torvalds： 嗯，嘿，我是出于我自己非常自私的原因做的。而且说真的，我的意思是，现在是再次强调这一点的时候：是的，在这 20 年里，我只花了四个月在它上面。所以…真的，所有的功劳都归于 Junio，以及所有参与 Git 的其他人，他们到目前为止所做的工作，远比我在任何方面做的都要多得多。

访谈者： 谢谢您。

要点回顾

一、 Git 诞生 20 周年回顾与 Linus 的看法

二、 Git 的起源：BitKeeper 事件与开发动机

三、 “十天”冲刺：Git 的快速原型开发

四、 Git 的核心设计哲学与关键决策

五、 早期发展、社区参与与维护权移交

六、 Git 的广泛普及与深远影响

七、 Linus 目前与 Git 的关系

八、 对 Git 未来的看法与挑战

九、 结语与致谢