这篇著名博客作家小饲弹对滨野纯的访谈，里面提及了滨野纯当初参与Git项目时的轶事，以及他对于开源项目的看法。特别是滨野纯说“Git是他第一次有一定规模地向开源项目提交代码”，很是鼓舞人——对那些想参与开源项目但缺乏信心的同学。所以趁闲把访谈全文翻译了一下。
今天我们的嘉宾，是分布式版本管理系统Git的主要维护者，同时也是《入门Git》一书的作者，滨野纯先生。而这次的访谈，也从滨野先生谈自己从Linux内核的开发者，Linus Torvalds手中接过Git维护工作的原委开始了。
结识Git的经过
小饲弹（以下简称弹）：当初是因为什么原因参与Git了的开发呢？
滨野纯（以下简称滨）：2005年4月起Linux Kernel所使用的版本管理系统BitKeeper就因为Licence关系无法继续使用了，所以Linus考察了很多当时的版本管理系统，但认为没有一个是能用的。于是他在邮件列表里发了一封邮件，说自己写了一些代码，准备作为在找到更好的版本管理系统之前的过渡系统。而我看到那封邮件时，正好是我的本职工作处于旧项目刚刚完成而新项目还未上马的间歇时期。我觉得这似乎是件挺有意思的事情，于是就把代码下载了下来，看了一下发现只有1244行。
弹：全部都是C代码吗？
滨：是啊。这点代码量我估计2小时左右应该就能读完了。仔仔细细地读了一遍以后，被代码所表现出来的优美折服了。基本上我不算是一个Kernel开发者，Kernel邮件列表也只是偶尔看一眼的程度而已。但是，如果说参与数十万行的Kernel开发确实有点困难的话，参与这个尚且才1000多行代码的项目应该会很有趣，这算是当初参与Git的动机之一。那时候，在一周时间内发生了很多事，不过归纳起来就是Linux的内核开发者们听说Linus要用个“新玩意”来管理代码，如果那个“新玩意”太难用的话大家都痛苦，还不如一起想办法把这个东西做好用点。而我也得以在开发中观察这个项目的进展，思考这个新系统真正需要的是什么等等，总之最后完成了提交commit的功能和输出diff的功能。不过，merge功能还没有完成。虽然Linus当时发过好几封邮件，描述他理想中的merge应该是怎样的。
弹：Linus对既往的版本管理系统，最不满的就是这方面吧。
滨：因为Linus只写C和Shell，而merge的逻辑实在太复杂，所以他多次发邮件到邮件列表，说要是有人能够用脚本语言实现一个就好了。不过谁也没有上钩。就这么过了一个星期，一直关注邮件列表的我用Perl把Linus过去多次提到的merge算法实现并投到了邮件列表里。这是我第一次有一定规模地向开源项目贡献代码。然而，尽管我详细地写了将近30个测试用例以及各种分支条件下应该怎么处理的表格，6个小时以后Linus提交到master分支的却是个截然不同的东西。据本人说是想到了更好的办法所以就这么着了。我看了一下，确实就像哥伦布的鸡蛋一样——足以让我那些依照Linus以前的逻辑所写的代码毫无价值——就是优雅到这种程度。不过之前你还说什么“谁来帮忙做一下啊”我做了结果你又不要（笑），然而当时并没有这么想，因为新的处理方法确实很漂亮。
哥伦布的鸡蛋
弹：为什么说是哥伦布的鸡蛋呢？
滨：我虽然没有使用过BitKeeper，不过BitKeeper的做法是在work tree里基本上只存放自己的文件，而merge不发生在这里。merge时首先会创建一个临时文件夹，在里面展开merge结果，发生冲突时就在里面解决，然后提交commit并在work tree里展开，这样就算merge完成了。最初Git也准备使用相同的流程，不过解决了冲突以后的代码，commit前想测试一下也是人之常情。所以我们就想那不如不要临时文件夹，直接在work tree上merge就行了…。Git在提交commit之前，不是有个记录了本次commit内容的index吗？对于这个index，当初提出了引入分步骤（stage）的概念。也就是说，，本来所谓3-way-merge就是，首先我们有一个共同的版本，你在这个版本的基础上做了一些变更，我在这个版本的基础上做了另一些变更，然后将这两个差分merge起来。那么把这三个版本分别作为stage1，stage2，stage3依次添加到index里，那merge不就完成了吗——Linus当时就是提出了这样的建议。仔细想想这种做法确实可以一下子解决很多问题。例如最简单的情况，我和你都没有做出变更，那么merge的结果就是没有变更。如果我做了变更而你没有，那么最后得到的就是我变更以后的代码，反之亦然。另外还有一种特殊的情况，就是你和我都做了“相同”的变更。
弹：这种事经常有啊（笑）。
滨：实际使用过以后发现确实如此，特别是Linux Kernel的开发，是基于邮件列表的。所以常有你我看到同一个patch，因为自己使用的版本是fix对象于是各自都打上了这个patch。这种情况也能在index中解决，不仅效率很高，结果也很清晰。
Linus的管理才能
滨：Linus常说，项目维护者的一半工作就是说No。不过即便如此，在拒绝别人提交的patch的时候，他总会向提交者强调，拒绝是因为这个提交不行，而不是你的能力不行。他对每个贡献者都很看重。我那时候也是，Linus对我说，虽然你的提交没有采用，但测试用例还是能用的，针对现在的实现你稍微修正一下吧。
弹：挺不错啊。
滨：让对方觉得自己的工作没有白费，这样就不会打击贡献者的热情。不仅提出新的merge算法很厉害，Linus作为社区管理者的才能也很厉害。不服不行啊（笑）。
GitHub
弹：GitHub和Git有组织上的联系吗？GitHub不是Git社区的人，而是Git爱好者做的吗？
滨：这个关系说来复杂了。GitHub的创始人都是Git社区以外的人。那些人基本上算是Ruby的人吧。Ruby社区开始大量使用Git应该是Rails采用Git作为版本管理以后的事。GitHub最初在还没有像现在这样流行之前，曾经采用邀请制试运营过一段时间，但是Git社区的主要成员却都没有收到邀请。虽然我个人不很在意，不过有些人觉得GitHub那群人在拿Git商业化所以很不爽，结果很长一段时间两个社区之间不怎么和睦。
弹：Git和GitHub是这种关系啊（笑）。都不很看重对方。
滨：经常会有无视对方自顾自地开发这种事，就比如官方Git和GitHub的Git的daemon程序在某些地方是不同的。GitHub做了一些他们自己的改动。面向大量用户做出这种非官方的版本，作为Git社区也很苦恼啊。
弹：是啊。
滨：然后呢，去年有一个GitTogether的活动，Google提供了场地，一共进行了三天吧，GitHub和Git社区的主要成员都来了，探讨了今后的发展方向，现在两个社区的关系应该没有过去那么差了。事实上，你也觉得GitHub的帮助文档很不错吧。有GitHub替我们做文档以及用户支持，何乐而不为呢。
弹：因为过去什么经验都没有的人也可以在GitHub上直接fork项目是吧。确实这种方式我觉得足以改变世界。从一开始就不仅是公开代码…。
滨：大家一起做一个项目，然后互相merge，这种工作流程很不错。
弹：我也是，如果没有GitHub的话也不会知道Git。
滨：是的，那是非常新颖的方式。尽管有些小地方很希望能够改一下，但是GitHub在普及Git上功不可没。
他们不计后果的彼此拥抱，握紧双手，怕天会亮，怕爱会走。
