Git 10 周年之际,创始人 Linus Torvalds 访谈 已翻译 100%

oschina 投递于 2015/04/07 08:22 (共 12 段, 翻译完成于 04-08)
阅读 8011
收藏 47
Git
6
加载中

十年前的这一周,linux 内核社区面临一个根本性的挑战:他们不再能够使用他们的修复控制系统:BitKeeper,同时其他的软件配置管理遇到了对分布式系统的新需求。Linus Torvalds,Linux的创始人,将这个挑战接手并消失了数周,创造了 Git 工具。今天 Git 被用于成千上万个工程,并且在程序员社区中掀起了一个新的社会化编码的浪潮。

为了庆祝这一里程碑,我们请 Linus 去分享 Git 的幕后故事,并且告诉我们这个工程队软件开发的影响。你会发现他在这个故事背后的的评论。我们跟随者Q&A追寻Git的轨迹,同时我们为其他的工程也描绘了轮廓。去查找KVM,Qt,Drupal,Puppet和wine背后的故事吧

p
panlingrui
翻译于 2015/04/07 12:11
2

为什么开发Git?

Torvalds: 我其实根本不想做源码管理,我认为源码管理是计算机领域最无趣的事(可能数据库更无趣 ;^)。我对SCM(源码管理工具)感到愤怒。但是BitKeeper的出现让我重新认识了源码管理。BK (BitKeeper)大多数都是正确的,但有本地副本的存储库与分布式合并是一个大问题。分布式源码管理的一个主要问题是源码管理的分离——谁才可以提交改变。BK展示了如何通过每个人都有源码库来避开这个问题。但是BK也有自己的问题:几种技术导制了这种问题(恼火的重命名),但最大的问题是它不开源,这让很多人不愿意使用它。因此,当我们以几个核心的维护使用BK而告终——它们是免费使用的开源项目——但它们无处不在。BK帮助了内核开发者,但是它还是有痛点。

wwq1001
wwq1001
翻译于 2015/04/07 19:02
2

当Tridge (Andrew Tridgell)对(相当简单的) BK 协议进行逆向工程--这是有悖于BK的使用规则的--的时候,事情到了不得不解决的地步。 我花了几个星期(几个月?我觉得是那样)在Tridge 和 Larry McVoy之间做调解,但是到最后,明显不起任何作用。于是,从那个时刻起,我决定不再继续使用BK,也不愿重回使用BK之前的糟透了的日子。同时,令人遗憾的是,一些其它的SCM,尝试着做分布式的事情,但是远程访问也没有处理好。我有性能的需求,不仅仅是满足远程可用,同时我还担心代码完整性和整个工作流,于是我决定自己写一个。

gones945
gones945
翻译于 2015/04/07 21:56
1

你是如何着手做这件事的?你是整个周末都在写代码,还是只在固定的几个小时呢?

Torvalds: 嗨,实际上,你可以从git的源代码仓库中,查看它是如何成型的,除了大概是最开始的一天。我大约花了一天时间来让git“自我管控”(self-hosting),这样,我就可以通过git来提交代码(commit)到git。所以大概第一天是隐藏的,但是所有其它的东西都在那里了。编码工作大多数在白天,但是也有少数在午夜,也有一些在凌晨2点。最有趣的部分是,它成型非常快;git树中的第一个commit并没有很多代码,但是它已经做了最基本的事情--可以提交(commit)自己。其中的技巧实际上不在于代码,而在于想出它如何组织数据的办法。

所以,我想说,git在大约10天左右的时间之后的样子(在这个点,我使用git做了*kernel*的第一次提交),它并不像某些疯狂的垃圾编码(而是有实际的使用价值)。早期的代码量实际上非常小,它的目标是正确实现基本点。 在整个项目开始之前,我一直在仔细考虑。我意识到其他人遇到的问题,也想到了要避免去做的事情。

gones945
gones945
翻译于 2015/04/07 22:51
1

它的存在周期达到了你的预期吗? 你认为它目前应该如何工作呢? 是否有一些限制呢?

Torvalds: 我对git非常满意。对于kernel的开发,它做的非常非常好,满足了我所有的预期。让我觉得有趣的是,它是如何接管了许多其它项目的。结果是令人吃惊的。在更换源代码管理系统的时候,有很大的惯性;看看CVS,甚至是RCS,它们占据了多长时间,但是,某个时刻起,git就完全接管了。

你觉得它为何如此广泛的被采用呢?

Torvalds: 我认为,其他许多人像我一样,都被同样的问题弄得灰心丧气,这些问题让我厌恶SCM。许多项目由于试着解决一两个边边角角的小问题而让人们抓狂,并不是像git这样真正的着手解决重要的问题。即便人们并不知晓“分布式”的部分有多么重要(许多人曾反对它),只要他们弄明白,git允许简单可靠的备份,同时允许人们生成他们自己私有的仓库,而不用担心一些中心仓库的拥有写访问权限的策略,他们是绝不会再回到以前的版本管理的。

gones945
gones945
翻译于 2015/04/07 23:17
1

Git会永远存在下去吗?或者说,您是否预见到在下一个10年中将会有其他的版本控制系统出现?你会是这个系统的作者之一吗?

Torvalds:不,我不会是这些作者中的一员。我们在10年内或许可以看到一些新的东西,但我保证这些东西也会是“类Git”的。这并不是说Git能正确地处理所有的事情,但它以一种前所未有的方式把最为基本的问题都解决了,在这之前没有一款软件配置管理工具(SCM)可以与之媲美。

我可以毫不谦虚地说 ;)

北风其凉
北风其凉
翻译于 2015/04/07 20:43
1

为什么Git能在Linux上工作得如此好?

Torvalds:好吧,很明显的它就是为了我们的工作流程而设计,因此他本身就是Linux的一部分。我已经多次提到完全“分布式”的部分,但它值得一再提及。它被设计得在面对像Linux的大型项目时有足够的效率,并且它被设计得去完成在它之前人们认为很“难”的任务——因为那些事情“我”每天都在做。

只举一个例子:代码合并的概念在多数源码管理工具中通常被认为是非常痛苦和困难的。你会计划你的代码合并,因为那是重大的决定。那样的情况对我而言不能接受,自从我一天在合并的窗口前做数十次的代码合并之后,最头疼的的问题不是代码合并工作本身,最重要的应该是检查其结果。Git中,代码合并只会花费数秒,编写代码合并的注释文字却会花费我很长时间。

因此,Git基本上按照我的需求设计和编码,也这样工作的。

观指居士
观指居士
翻译于 2015/04/07 22:01
1

有人说Git只是为聪明人设计的,甚至连Andrew Morton都说:“Git经过特意设计,以便让你感到自己不够聪明。”您对此有何回应?

Torvalds:我想在以前确实如此,但现在不同了。因为某些原因,人们觉得git难用,但我认为现在只剩一个原因,那就是:你可以用很多种方法完成一件事。

通过git你可以完成很多事请,git要求人们遵守许多规则,这些规则并非出于技术上的限制,而是为了让人们可以更好的合作。git是一个强大的工具,开始使用时你会感觉很困难,这通常是因为你可以用不同方法完成一件事,而且这些方法都能工作!一般说来,学习git最好的方法可能是,你先用它做最基本的事情,直到你熟悉这些基本操作,再去了解git的其它用法。

Serval
Serval
翻译于 2015/04/07 23:02
1

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字节的十六进制数呢?

Serval
Serval
翻译于 2015/04/07 23:26
1

但git并不是要故意标新立异。git确实和CVS存在差异,因为人们有不同的知识背景,所以这些差异使人们感觉其中一个比另一个复杂。CVS背景的东西正在渐渐远去,可能现在很多用过git的人从来没有用过CVS,他们就会不习惯CVS的使用方式。

你认为没有git,Linux Kernel能达到目前的开发速度吗?

Torvalds:呃,没有git,我认为可以。但那意味着需要有人写出与git相似的工具:一个像git一样高效的分布式的SCM。没错,我们确实需要像git这样的东西。

Serval
Serval
翻译于 2015/04/07 23:38
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(28)

理工小强
理工小强
各有各的好处吧 微软也有免费托管的商业git库的
泡不烂的凉粉
泡不烂的凉粉

引用来自“Raymin”的评论

感觉 Git 真的没必要用 C 写,太浪费精力,用 Perl Python 什么的都行。
问题是:如果 Git 是用脚本语言写的,git@osc github 性能受影响不?
要说git , 其实git是C来写的不错。但是,它所依赖的环境,就没办法那么好移植了。 并且很多工具本身就是用perl来写的。 使用了很多shell 下的实用工具。所以windows平台下的版本都用 msys环境或者类似环境。
哆啦比猫
哆啦比猫

引用来自“lln133208”的评论

我接触的第一个版本管理工具就是git,反而觉得好学点,是不是因为没有先入为主的影响?

引用来自“Haven200”的评论

我学的我一个版本管理工具也是git,同样没感觉难学来着
同样是第一个版本管理工具是 git,感觉挺简单 尤其是后期遇到很多版本管理的问题(比如改错了 branch 还没提交该怎么处理)发现git都有很好的解决方案
Haven200
Haven200

引用来自“lln133208”的评论

我接触的第一个版本管理工具就是git,反而觉得好学点,是不是因为没有先入为主的影响?
我学的我一个版本管理工具也是git,同样没感觉难学来着
大__大
大__大
就想说,在SVN早期的版本,好像是1.7之前,每个目录都带一个.svn的目录,直接就想吐
Beyonds
Beyonds
git好用
lln133208
lln133208

引用来自“lln133208”的评论

我接触的第一个版本管理工具就是git,反而觉得好学点,是不是因为没有先入为主的影响?

引用来自“QuenTine”的评论

是,我用的第一个vcs是svn所以觉得git太复杂,但是用惯了之后发现git的三层提交很有必要。
嗯,设计思想还是很牛的,基本上知道了基本操作就可以进行开发了,原理可以在空余时间自己研究。
Iridium
Iridium

引用来自“Iridium”的评论

依次用过较长时间的 CVS,SVN,git,用的时候,都感觉很不错,当一旦用上后面的工具时,根本就不想回去用原来的了。

短暂用过微软的一个版本管理工具(名字忘了)和 Clear Case(名字好像是这样拼的),这两个工具简直是反人类设计。

引用来自“小肥侠”的评论

微软的叫tfs.

引用来自“samfisher”的评论

Visual SourceSafe吧,没想到差点想不起这名字。
对,就是它!它有个锁机制,只要某文件被锁了,那个加锁的人不释放,你就别想修改。。。 有点类似“悲观锁”,搞得人很崩溃,幸好用的时间很短。
jude
jude

引用来自“难易”的评论

linus自己有需求,并有能力去实现。这是最好的。
精辟
朱永波
朱永波
向Linus致敬……
返回顶部
顶部