十年前的这一周,linux 内核社区面临一个根本性的挑战:他们再也不可以使用他们的修复控制系统:BitKeeper,同时其余的软件配置管理遇到了对分布式系统的新需求。Linus Torvalds,Linux的创始人,将这个挑战接手并消失了数周,创造了 Git 工具。今天 Git 被用于成千上万个工程,而且在程序员社区中掀起了一个新的社会化编码的浪潮。linux
为了庆祝这一里程碑,咱们请 Linus 去分享 Git 的幕后故事,而且告诉咱们这个工程队软件开发的影响。你会发现他在这个故事背后的的评论。咱们跟随者Q&A追寻Git的轨迹,同时咱们为其余的工程也描绘了轮廓。去查找KVM,Qt,Drupal,Puppet和wine背后的故事吧git
为何开发Git?程序员
Torvalds: 我其实根本不想作源码管理,我认为源码管理是计算机领域最无趣的事(可能数据库更无趣 ;^)。我对SCM(源码管理工具)感到愤怒。可是BitKeeper的出现让我从新认识了源码管理。BK (BitKeeper)大多数都是正确的,但有本地副本的存储库与分布式合并是一个大问题。分布式源码管理的一个主要问题是源码管理的分离——谁才能够提交改变。BK展现了如何经过每一个人都有源码库来避开这个问题。可是BK也有本身的问题:几种技术导制了这种问题(恼火的重命名),但最大的问题是它不开源,这让不少人不肯意使用它。所以,当咱们以几个核心的维护使用BK而了结——它们是无偿使用的开源项目——但它们无处不在。BK帮助了内核开发者,可是它仍是有痛点。数据库
当Tridge (Andrew Tridgell)对(至关简单的) BK 协议进行逆向工程–这是有悖于BK的使用规则的–的时候,事情到了不起不解决的地步。 我花了几个星期(几个月?我以为是那样)在Tridge 和 Larry McVoy之间作调解,可是到最后,明显不起任何做用。因而,从那个时刻起,我决定再也不继续使用BK,也不肯重回使用BK以前的糟透了的日子。同时,使人遗憾的是,一些其它的SCM,尝试着作分布式的事情,可是远程访问也没有处理好。我有性能的需求,不只仅是知足远程可用,同时我还担忧代码完整性和整个工做流,因而我决定本身写一个。编程
你是如何着手作这件事的?你是整个周末都在写代码,仍是只在固定的几个小时呢?分布式
Torvalds: 嗨,实际上,你能够从git的源代码仓库中,查看它是如何成型的,除了大概是最开始的一天。我大约花了一天时间来让git“自我管控”(self-hosting),这样,我就能够经过git来提交代码(commit)到git。因此大概第一天是隐藏的,可是全部其它的东西都在那里了。编码工做大多数在白天,可是也有少数在午夜,也有一些在凌晨2点。最有趣的部分是,它成型很是快;git树中的第一个commit并无不少代码,可是它已经作了最基本的事情–能够提交(commit)本身。其中的技巧实际上不在于代码,而在于想出它如何组织数据的办法。工具
因此,我想说,git在大约10天左右的时间以后的样子(在这个点,我使用git作了*kernel*的第一次提交),它并不像某些疯狂的垃圾编码(而是有实际的使用价值)。早期的代码量实际上很是小,它的目标是正确实现基本点。 在整个项目开始以前,我一直在仔细考虑。我意识到其余人遇到的问题,也想到了要避免去作的事情。性能
它的存在周期达到了你的预期吗? 你认为它目前应该如何工做呢? 是否有一些限制呢?学习
Torvalds: 我对git很是满意。对于kernel的开发,它作的很是很是好,知足了我全部的预期。让我以为有趣的是,它是如何接管了许多其它项目的。结果是使人吃惊的。在更换源代码管理系统的时候,有很大的惯性;看看CVS,甚至是RCS,它们占据了多长时间,可是,某个时刻起,git就彻底接管了。编码
你以为它为什么如此普遍的被采用呢?
Torvalds: 我认为,其余许多人像我同样,都被一样的问题弄得灰心丧气,这些问题让我厌恶SCM。许多项目因为试着解决一两个边边角角的小问题而让人们抓狂,并非像git这样真正的着手解决重要的问题。即使人们并不知晓“分布式”的部分有多么重要(许多人曾反对它),只要他们弄明白,git容许简单可靠的备份,同时容许人们生成他们本身私有的仓库,而不用担忧一些中心仓库的拥有写访问权限的策略,他们是毫不会再回到之前的版本管理的。
Git会永远存在下去吗?或者说,您是否预见到在下一个10年中将会有其余的版本控制系统出现?你会是这个系统的做者之一吗?
Torvalds:不,我不会是这些做者中的一员。咱们在10年内或许能够看到一些新的东西,但我保证这些东西也会是“类Git”的。这并非说Git能正确地处理全部的事情,但它以一种史无前例的方式把最为基本的问题都解决了,在这以前没有一款软件配置管理工具(SCM)能够与之媲美。
我能够绝不谦虚地说 ;)
为何Git能在Linux上工做得如此好?
Torvalds:好吧,很明显的它就是为了咱们的工做流程而设计,所以他自己就是Linux的一部分。我已经屡次提到彻底的“分布式”部分,但它值得一再说起。它被设计得在面对如Linux的大型项目时有足够的效率,而且它被设计得去完成在它以前人们认为很“难”的任务——由于那些事情我天天都在作。
只举一个例子:代码合并的概念在多数源码管理工具中一般被认为是很是痛苦和困难的事。你会计划你的代码合并,由于那是重大的决定。那样的状况对我而言不能接受,自从我一天在合并的窗口前作数十次的代码合并以后,最头疼的的问题不是代码合并工做自己,最重要的应该是检查其结果。Git中,代码合并只会花费数秒,编写代码合并注释文字却会花费我很长的时间。
所以,Git基本上按照个人需求设计和编码,也这样实现。
有人说Git只是为聪明人设计的,甚至连Andrew Morton都说:“Git通过特地设计,以便让你感到本身不够聪明。”您对此有何回应?
Torvalds:我想在之前确实如此,但如今不一样了。由于某些缘由,人们以为git难用,但我认为如今只剩一个缘由,那就是:你能够用不少种方法完成一件事。
经过git你能够完成不少事请,git要求人们遵照许多规则,这些规则并不是出于技术上的限制,而是为了让人们能够更好的合做。git是一个强大的工具,开始使用时你会感受很困难,这一般是由于你能够用不一样方法完成一件事,并且这些方法都能工做!通常说来,学习git最好的方法多是,你先用它作最基本的事情,直到你熟悉这些基本操做,再去了解git的其它用法。
git的复杂有一些历史缘由,其中之一是:它过去就很复杂!git的早期用户是那些为Kernel编程的人,他们不得不学习一系列很是难用的脚本。把绝大多数的精力花费在让git能用,而不是更易用。因此早期git给你们的印象(确实就)是,你必须很清楚本身在作什么。固然,在最初的半年或一年里,事实确实如此。
人们感受git复杂的另外一个缘由:git不一样以往的SCM。许多人使用CVS十年甚至二十年,但git不是CVS,它们一点也不像。git和CVS的设计理念不一样,命令也不一样。git历来没有想过模仿CVS,甚至相反。若是你曾经长时间使用CVS风格的SCM系统,就会感受git很复杂,而且以为那些和CVS不一样的设计没有存在的必要。奇怪的修订编号会让你分心,你心想:为何git的修订编号不能像CVS的1.3.1那样累加,而要选择一个奇怪的40字节的十六进制数呢?
但git并非要故意标新立异。git确实和CVS存在差别,由于人们有不一样的知识背景,因此这些差别令人们感受其中一个比另外一个复杂。CVS背景的东西正在渐渐远去,可能如今不少用过git的人历来没有用过CVS,他们就会不习惯CVS的使用方式。
你认为没有git,Linux Kernel能达到目前的开发速度吗?
Torvalds:呃,没有git,我认为能够。但那意味着须要有人写出与git类似的工具:一个像git同样高效的分布式的SCM。没错,咱们确实须要像git这样的东西。
您目前对GitHub有何见解?
Torvalds:毫无疑问,Github是一个很是棒的代码托管服务,但我对它仍有一些见解:作为一个开发平台(提交代码,请求更新,跟踪issue等),GitHub有太多限制。它远不如Kernel的开发平台那样出色。
部分缘由是因为Kernel的开发方式——git正是为Kernel开发而生,但另外一部分缘由是GitHub的界面鼓励很差的行为。好比,GitHub上的“完成提交”有一些很差的提交信息。GitHub曾经修复了一些问题,也许如今已经作得很好了,但它永远不能像Linux Kernel那样,和git完美结合。
请说一说在 Git 或 GitHub 上您最感兴趣的用法?
Torvalds:很高兴看到采用git能够很轻松的建立一个项目。之前的代码托管很难用,有了git和GitHub,建立一些小项目变得很是简单。项目具体是作什么并不重要,重要的是你能够作到了。
您最近还有其它项目吗?其它能够统治将来若干年软件开发的伟大项目?
Torvalds:目前没有,若是有的话我会告诉你。