为什么开发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，甚至相反。如果你曾经长时间使用CVS风格的系统，就会感觉git很复杂，并且那些和CVS不同的设计，显得没有必要。人们会因奇怪的修订编号而分心。为什么git的修订编号不能像CVS的1.3.1那样累加，而是要选择一个奇怪的40字节的十六进制数？

但git并不是要表现“没有必要的差异”。git确实和CVS存在差异。这些差异使人们感觉其中一个比另一个复杂，那是因为他们有不同的知识背景。CVS背景的东西正在远去。可能现在很多人从来没有用过CVS，他们会不理解CVS的使用方式，因为他们先学习了git。

你认为没有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：目前没有，如果有的话我会告诉你。