十年前的这一周，Linux内核开发社区正面临严峻的挑战：他们不能继续使用BitKeeper了（注：原因是当时Bitkeeper著作权所有者决定收回授权，内核开发团队与其协商无果），而又没有其他的SCM（SoftwareConfigurationManagement）可满足他们的分布式系统的需求。Linux之父LinusTorvalds接受了这个挑战，决定开发一个新的版本控制系统。周末他消失了，新的一周，Git问世了。今天，Git已经成为上万个项目的版本控制系统，并且在程序员中引发了开源热潮。
为了庆祝里程碑式的一刻，Linux基金会邀请了LinusTorvalds来分享Git背后的故事，以及他对Git在软件开发中的影响的观点。
你为什么要开发Git？Torvalds：我从来没有想过去做版本控制软件，因为在我看来那是计算机世界里最无聊的事了（如果数据库除外的话;^），我天生就不喜欢SCM。但是Bitkeeper的诞生改变了我对版本控制的认识。BK在大多数方面是正确的，在本地保存一个仓库的副本，分布式合并确实是一大创新。这个分布式版本控制的创新完美地解决了SCM的通病：“谁可以修改代码”的难题。BK告诉我们，你只要给每个人一个仓库，问题就解决了。但是BK也存在一些问题，技术上的问题（例如重命名很麻烦）还不算什么，它最大的坏处是不开源，很多人因为这个不使用它。所以即使我们有几个核心维护者使用BK——开源项目可以免费使用——但它也没有普及。虽然它帮助过我们开发内核，但依然有不少痛点没有解决。
当Tridge违反BK的使用协议反编译BK的时候，我们到达了紧急关头。我花了几个周（还是几个月来着？）试图调解Tridge和LarryMcVoy（注：他是Bitkeeper的老大），最后也没有成功。我意识到我不能继续使用BK了，但我真的不想回到没有BK的黑暗时代。遗憾的是，我们想用其他SCM来代替它，却没有找到能在远程方面工作得好的。现有的软件不能满足我对远程方面的需求，我又担心整个流程和代码的完整性，所以最后我决定自己写一个。
你怎么做到的？整个周末都在熬夜写这个，还是只用了常规的时间？Torvalds：呵呵，其实可以在Git的源代码仓库中看它是如何成型的。除了第一天的工作，因为我花了一天的时间进入“自举(self-hosting)”。之后我就能使用Git向Git自己提交代码了，虽然第一天所有的东西都不是明确的，但是大体上也都在那里了。虽然这些工作大多是在白天完成的，但也有时候工作到了深夜，甚至有两天到了凌晨两点。最有趣的部分是如何将它快速成型。Git树中的第一次提交没有太多代码，但是它的基本功能已经实现了——向它自己提交代码。这部分写代码并不难，难的是如何组织数据。
所以我想强调的是，虽然它在短短十天内就完成了（我第一次使用git向内核提交代码的时间），但是这并不是某种“马拉松”式的开发。事实上，我早期的开发成本很低，这取决于基本的思路正确。在这个项目开始之前，我想了很久，我总结了很多别人犯过的错误，然后极力避免了。
Git达到了你的期望吗？你估计一下它现在工作得如何？它还有什么不足吗？Torvalds：我对Git很满意。它工作得相当出色，满足了我的所有需求。有趣的是，它还接手了很多其他项目，它成长地相当迅速。在切换版本控制系统中有很多惰性，看看CVS和RCS这些坚持了这么久就知道了。不过等时机到了，Git早晚都会接管过来。
你觉得为什么它会被如此广泛地接受？Torvalds：我提过以前我为什么痛恨SCM，我相信很多人也为相同的问题烦恼过。很多项目要改一两个小地方就会使人抓狂。在Git之前，没有东西来真正解决这个问题。人们不清楚分布式的重要性，可能还会与此抗争。一旦他们明白它支持的方便可靠的备份，并允许做私人的测试仓库，而不必担心有无中央存储仓库的权限的话，他们就永远不会放弃Git了。
Git会永远流行吗？还是你预见在将来的十年会有另一种版本控制系统？作者会是你吗？Torvalds：我不会是唯一一个作者，将来我们也可能使用另一种工具，但是我敢保证，它一定和Git非常像（“git-like”）。我不是说Git的什么都是对的，但它的基本路线是对的，之前其他SCM未曾尝试过。
没有假谦虚:)
为什么Git能在Linux上工作地这么好呢？Torvalds：很显然，Git最初是为我们的工作流程设计的，所以这是它的一部分。虽然我重复“分布式”这个词很多次了，但这不为过。它被设计为足以高效地应付像Linux一样的大项目，它也用于完成Git之前人们觉得“艰难”的事情——因为这些事我每天都要做。
举个例子吧：在大多数的SCM中，“merging”操作都被认为是痛苦而且艰难的事情。你需要计划好你的合并操作，因为这涉及到很多繁琐的细节。这我不能接受，因为我每天要做几十次合并，即使这样，最大的麻烦还不是合并本身，而是测试结果。“Git”的合并只需要几秒钟，写合并注释反而会花去我更多的时间。
所以Git基本上是为了满足我的需求来写的。
人们说Git是为聪明人设计的，即使AndrewMorton也说“Git的明确设计让你感觉你比你想象中的要蠢。”你对此的回应是什么呢？Torvalds：我觉得曾经可能是这样的，但现在不再是了。人们这么想可能会有很多原因，但只有一个站得住脚，很简单：“在Git中完成一件事你有太多的方法”。
使用Git你可以做很多事，大多数“你应该怎样”的规则，其实并不是技术上的限制，而是建议，这样你和别人一起工作的时候可以配合得更好。Git是一个强大的工具，但是你不能因为这个望而却步。虽然你可以每次用不同的方法完成相同的事情，但在多数情况下，学习Git的最好方法还是从最基本的事情做起。直到你熟悉基本操作了，再去接触别的东西。
Git给人复杂的印象有一些历史原因。其中一个是，它很早之前确实是复杂的。一开始需要使用Git来做内核方面的工作的时候，人们要配置一些脚本。那时候的工作主要集中于让核心模块工作，花在易用性方面的精力很少。所以很显然，Git因其复杂性著称，但那大约还是头一年的事了。
人们认为Git难的原因是Git的与众不同。很多人用过十几二十年的CVS，但Git并不是CVS，一点都不像。概念不同，命令也不同。Git从来没有考虑过要像CVS，甚至大行反道。所以如果你使用CVS之类的系统很长时间，就会觉得Git复杂，而且它的差异毫无必要。人们会对版本号码感到奇怪。为什么Git的版本不像CVS的“1..1”这种递增式的数字？为什么会是恐怖的四十位Hex码？
但Git的不同并不是“毫无必要的”。只是这点让人们觉得它太复杂了，因为它来自一个不同的背景。“CVS”的背景过时了。现在很多程序员从没用过CVS，如果他们学CVS，可能觉得CVS的方式太诡异了，因为他们最先学的Git。
如果没有Git，Linux内核会发展的像现在这样好吗？为什么？Torvalds：“没有Git”，好吧，但是一定会有别人写出来个像Git的工具，一个分布式版本控制系统。毫无疑问，我们需要“Git”这样的东西。
你怎么看待Github？Torvalds：Github是非常棒的代码托管服务，对此我没有任何反对。我的抱怨主要是因为它作为一个开发平台——提交代码，pullrequest，跟踪问题等等——不够好。不适用于内核之类的项目。限制太多了。
部分原因是，因为内核发展的原因，部分是因为Github的接口很鼓励坏习惯。在Github的提交有不好的提交信息等等，就是因为接口的问题。他们确实做了改善，可能现在好点了，可是永远不会适用于Linux内核这样的项目。
你见过的用Git/Github做的最有趣的事情是什么？Torvalds：看到创建一个新项目能如此简单，我很开心。以前搞代码托管很痛苦的，但现在用Git/Github，创建一个小项目就小菜一碟了。你的项目是什么并不重要，重要的是你可以做得到。
你现在有什么精彩的项目吗？有什么将推动软件发展软件吗？Torvalds：暂时没有，如果有的话，我会告诉你。
为纪念Git面世十周年，Atlassian还特别制作了一个交互信息图，回顾了Git的发展历程（各个重要里程碑）。点击这里或下图，可以欣赏。真心赞！
原文：
转载请注明：http://www.0431gb208.com/sjslczl/1289.html
