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

十年前的这一周,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 ,创建一个小项目就小菜一碟了。你的项目是什么并不重要,重要的是你可以做得到。

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

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

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

你也许感兴趣的:

共有 1 条讨论

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注