Git 10 周年访谈：Linus 讲述背后故事

linus 访谈| 2015-06-15

十年前的这一周，Linux 内核开发社区正面临严峻的挑战：他们不能继续使用 BitKeeper 了（伯乐在线注：原因是当时Bitkeeper 著作权所有者决定收回授权，内核开发团队与其协商无果），而又没有其他的 SCM （Software Configuration Management）可满足他们的分布式系统的需求。Linux 之父 Linus Torvalds 接受了这个挑战，决定开发一个新的版本控制系统。周末他消失了，新的一周，Git 问世了。今天，Git 已经成为上万个项目的版本控制系统，并且在程序员中引发了开源热潮。

为了庆祝里程碑式的一刻，Linux 基金会邀请了 Linus 来分享 Git 背后的故事，以及他对 Git 在软件开发中的影响的观点。

Linus_Torvalds_(cropped)

Linus Torvalds

你为什么要开发 Git？

Torvalds：我从来没有想过去做版本控制软件，因为在我看来那是计算机世界里最无聊的事了（如果数据库除外的话 ;^），我天生就不喜欢 SCM。但是 Bitkeeper 的诞生改变了我对版本控制的认识。BK 在大多数方面是正确的，在本地保存一个仓库的副本，分布式合并确实是一大创新。这个分布式版本控制的创新完美地解决了 SCM 的通病：“谁可以修改代码”的难题。BK 告诉我们，你只要给每个人一个仓库，问题就解决了。但是 BK 也存在一些问题，技术上的问题（例如重命名很麻烦）还不算什么，它最大的坏处是不开源，很多人因为这个不使用它。所以即使我们有几个核心维护者使用 BK——开源项目可以免费使用——但它也没有普及。虽然它帮助过我们开发内核，但依然有不少痛点没有解决。

当 Tridge 违反 BK 的使用协议反编译 BK 的时候，我们到达了紧急关头。我花了几个周（还是几个月来着？）试图调解 Tridge 和 Larry McVoy（伯乐在线注：他是 Bitkeeper 的老大），最后也没有成功。我意识到我不能继续使用 BK 了，但我真的不想回到没有 BK 的黑暗时代。遗憾的是，我们想用其他 SCM 来代替它，却没有找到能在远程方面工作得好的。现有的软件不能满足我对远程方面的需求，我又担心整个流程和代码的完整性，所以最后我决定自己写一个。

你怎么做到的？整个周末都在熬夜写这个，还是只用了常规的时间？

T：呵呵，其实可以在 Git 的源代码仓库中看它是如何成型的。除了第一天的工作，因为我花了一天的时间进入“自举(self-hosting)”。之后我就能使用 Git 向 Git 自己提交代码了，虽然第一天所有的东西都不是明确的，但是大体上也都在那里了。虽然这些工作大多是在白天完成的，但也有时候工作到了深夜，甚至有两天到了凌晨两点。最有趣的部分是如何将它快速成型。Git 树中的第一次提交没有太多代码，但是它的基本功能已经实现了——向它自己提交代码。这部分写代码并不难，难的是如何组织数据。

所以我想强调的是，虽然它在短短十天内就完成了（我第一次使用 git 向内核提交代码的时间），但是这并不是某种“马拉松”式的开发。事实上，我早期的开发成本很低，这取决于基本的思路正确。在这个项目开始之前，我想了很久，我总结了很多别人犯过的错误，然后极力避免了。

Git 达到了你的期望吗？你估计一下它现在工作得如何？它还有什么不足吗？

我对 Git 很满意。它工作得相当出色，满足了我的所有需求。有趣的是，它还接手了很多其他项目，它成长地相当迅速。在切换版本控制系统中有很多惰性，看看 CVS 和 RCS 这些坚持了这么久就知道了。不过等时机到了，Git 早晚都会接管过来。

你觉得为什么它会被如此广泛地接受？

我提过以前我为什么痛恨 SCM，我相信很多人也为相同的问题烦恼过。很多项目要改一两个小地方就会使人抓狂。在 Git 之前，没有东西来真正解决这个问题。人们不清楚分布式的重要性，可能还会与此抗争。一旦他们明白它支持的方便可靠的备份，并允许做私人的测试仓库，而不必担心有无中央存储仓库的权限的话，他们就永远不会放弃 Git 了。

Git 会永远流行吗？还是你预见在将来的十年会有另一种版本控制系统？作者会是你吗？

我不会是唯一一个作者，将来我们也可能使用另一种工具，但是我敢保证，它一定和 Git 非常像（“git-like”）。我不是说 Git 的什么都是对的，但它的基本路线是对的，之前其他 SCM 未曾尝试过。

没有假谦虚 🙂

为什么 Git 能在 Linux 上工作地这么好呢？

很显然，Git 最初是为我们的工作流程设计的，所以这是它的一部分。虽然我重复“分布式”这个词很多次了，但这不为过。它被设计为足以高效地应付像 Linux 一样的大项目，它也用于完成 Git 之前人们觉得“艰难”的事情——因为这些事我每天都要做。

举个例子吧：在大多数的 SCM 中，“merging” 操作都被认为是痛苦而且艰难的事情。你需要计划好你的合并操作，因为这涉及到很多繁琐的细节。这我不能接受，因为我每天要做几十次合并，即使这样，最大的麻烦还不是合并本身，而是测试结果。“Git”的合并只需要几秒钟，写合并注释反而会花去我更多的时间。

所以 Git 基本上是为了满足我的需求来写的。

人们说 Git 是为聪明人设计的，即使 Andrew Morton 也说 “Git的明确设计让你感觉你比你想象中的要蠢。”你对此的回应是什么呢？

我觉得曾经可能是这样的，但现在不再是了。人们这么想可能会有很多原因，但只有一个站得住脚，很简单：“在 Git 中完成一件事你有太多的方法”。

使用 Git 你可以做很多事，大多数“你应该怎样”的规则，其实并不是技术上的限制，而是建议，这样你和别人一起工作的时候可以配合得更好。Git 是一个强大的工具，但是你不能因为这个望而却步。虽然你可以每次用不同的方法完成相同的事情，但在多数情况下，学习 Git 的最好方法还是从最基本的事情做起。直到你熟悉基本操作了，再去接触别的东西。（伯乐在线插播推荐几篇文章：《Git 两分钟指南》、《写给 Git 初学者的 7 个建议》、《图解 Git /图形化的 Git 参考手册》、《给 Git 中级用户的 25 个小贴士》、《让Git 水平更上一层楼的 10 个小贴士》。）

Git 给人复杂的印象有一些历史原因。其中一个是，它很早之前确实是复杂的。一开始需要使用 Git 来做内核方面的工作的时候，人们要配置一些脚本。那时候的工作主要集中于让核心模块工作，花在易用性方面的精力很少。所以很显然，Git 因其复杂性著称，但那大约还是头一年的事了。

人们认为 Git 难的原因是 Git 的与众不同。很多人用过十几二十年的 CVS，但 Git 并不是 CVS，一点都不像。概念不同，命令也不同。Git 从来没有考虑过要像 CVS，甚至大行反道。所以如果你使用 CVS 之类的系统很长时间，就会觉得 Git 复杂，而且它的差异毫无必要。人们会对版本号码感到奇怪。为什么 Git 的版本不像 CVS 的“1.3.1”这种递增式的数字？为什么会是恐怖的四十位 Hex 码？

但 Git 的不同并不是“毫无必要的”。只是这点让人们觉得它太复杂了，因为它来自一个不同的背景。“CVS”的背景过时了。现在很多程序员从没用过 CVS，如果他们学 CVS，可能觉得 CVS 的方式太诡异了，因为他们最先学的 Git。

如果没有 Git，Linux 内核会发展的像现在这样好吗？为什么？

“没有 Git”，好吧，但是一定会有别人写出来个像 Git 的工具，一个分布式版本控制系统。毫无疑问，我们需要“Git”这样的东西。

你怎么看待 Github ？

Github 是非常棒的代码托管服务，对此我没有任何反对。我的抱怨主要是因为它作为一个开发平台——提交代码，pull request，跟踪问题等等——不够好。不适用于内核之类的项目。限制太多了。

部分原因是，因为内核发展的原因，部分是因为 Github 的接口很鼓励坏习惯。在 Github 的提交有不好的提交信息等等，就是因为接口的问题。他们确实做了改善，可能现在好点了，可是永远不会适用于 Linux 内核这样的项目。

你见过的用 Git/Github 做的最有趣的事情是什么？

看到创建一个新项目能如此简单，我很开心。以前搞代码托管很痛苦的，但现在用 Git/Github ，创建一个小项目就小菜一碟了。你的项目是什么并不重要，重要的是你可以做得到。

你现在有什么精彩的项目吗？有什么将推动软件发展软件吗？

暂时没有，如果有的话，我会告诉你。

本文文字及图片出自伯乐在线