Git 10 周年访谈：Linus 讲述背后故事
【伯乐在线导读】：十年前的这一周，Linux 内核开发社区正面临严峻的挑战：他们不能继续使用 BitKeeper 了（伯乐在线注：原因是当时Bitkeeper 著作权所有者决定收回授权，内核开发团队与其协商无果），而又没有其他的 SCM （Software Configuration Management）可满足他们的分布式系统的需求。Linux 之父 Linus Torvalds 接受了这个挑战，决定开发一个新的版本控制系统。周末他消失了，新的一周，Git 问世了。今天，Git 已经成为上万个项目的版本控制系统，并且在程序员中引发了开源热潮。
为了庆祝里程碑式的一刻，Linux 基金会邀请了 Linus 来分享 Git 背后的故事，以及他对 Git 在软件开发中的影响的观点。
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 ，创建一个小项目就小菜一碟了。你的项目是什么并不重要，重要的是你可以做得到。
你现在有什么精彩的项目吗？有什么将推动软件发展软件吗？
暂时没有，如果有的话，我会告诉你。
【伯乐在线注】：为纪念 Git 面世十周年， Atlassian 还特别制作了一个交互信息图，回顾了 Git 的发展历程（各个重要里程碑）。点击这里或下图，可以欣赏。真心赞！
关于作者：赖信涛
转载自：http://blog.jobbole.com/85772/
