重生之农家军嫂书包网:GitHub与Erlang的互利共赢之路

　　概要 
　　om Preston-Werner介绍了Git和GitHub，并回答了关于GitHub架构和特性的相关问题。同时还介绍了GitHub的开发流程以及对Erlang的使用如何有助于搭建更健壮的系统。Kenneth Ludin谈及了Erlang/OTP团队将代码托管迁移到GitHub的决策过程，这对于提升社区的贡献产生了什么影响。 

　　个人简介 
　　Tom Preston-Werner是Powerset公司的员工，也是GitHub的创始人之一。他开发了许多Ruby工具，比如监控工具god等等。Kenneth Lundin于1996年项目的初期阶段就加入了Erlang/OTP团队，从那时起他的工作同时涉及应用层面和运行时系统层面。迄今为止他已经管理这个团队近十年了。 

　　关于会议 
　　Erlang Factory是关于Erlang的业界盛会，Erlang是为支持分布式、高容错、软实时的需求而设计的计算机语言，同时支持高可靠性和高并发性。Erlang Factory的重头戏是峰会——为时两天的峰会涵盖了各种主题的分会，并且不时会遇见Erlang业界的领袖或是使用及应用层面的许多专家。

　　受访人 Tom Preston-Werner & Kenneth Lundin 采访人 Sadek Drobi 译者 黄璜

　　能不能给我们简单介绍一下自己，以及你所从事的工作？

　　我是GitHub的联合创始人及CTO。我们公司主要是运营Git托管和开发协作工具。我们还做关于Git的培训，也有供企业使用的本地版本，并乐于参加各种会议。我们就像是Git的布道者，告诉人们它如何帮助改进业务，并且能帮助他们进行更有效的代码开发和协作。

　　我是Kenneth Lundin，爱立信Erlang OTP团队的经理，发布了?Erlang OTP开源软件。

　　人们大多对?Git有所耳闻，许多人?认为它是又一个SVN，或是分布式SVN，这显然不是重点。你能够向那些想要学习Git的人们介绍一下Git的核心概念吗？

　　Git与Subversion、CVS、RCS等等属于同一产品线，但却有一定意义上的革新性。Subversion和CVS是集中式的存储。所有的代码都在服务器一处地方，人们使用客户端来与中心服务器进行通讯。每个人都是与中心服务器通讯。如果中心服务器出了什么差错了话，你就没那么幸运了。基本上你什么办法也没有。从这里就演化出了分布式版本控制这一思想。

　　你可以让每个代码库都是一个完整的库，拥有完整的历史，而不是只有一个中心库。每个开发者都有一个代码库的克隆，可以离线编辑并且进行提交，这是因为是在本地的，所以他们只是提交到了本地的版本库。然后，在分布式的基础上，推送提交也是很容易的。你可以将修改的结果推送给其它用户，或者通过中心模型推送给一系列用户。你仍然可以使用中心模型，同时你也得到分布机制的可靠保证，不会出现单点失效的情况。

　　开发者仍然可以在本地工作和提交，做一系列的操作。这只是把源码控制这一概念发扬光大了，给予开发者更多本地操作的范围。Git做得非常好的另外一点是分支。在Subversion、CVS等系统中，创建分支，作一些提交，而主线经过提交后你需要再做分支的时候，会是一件很麻烦的事。Git把它做成了中心式的概念。

　　Git通过什么样的方式简化了fork和merge? 

　　假设你正在参与开源项目，比如Erlang。你想要签出代码，进行一些修改，然后提交回主线以便进行合并。按传统的方式比如subversion或CVS，?你是在处理patch文件。你在本地进行一些修改，最后做成一个patch文件，发到邮件列表或者给某个你知道的人。使用Git内嵌的分支特性，这是一个核心概念，你只需要做一个分支，以你想要的特性为名字，进行提交，也许你做了5次提交(都是逻辑上的代码片段提交)。

　　然后，你可以将代码推送到中心结点，比如GitHub，然后你可以通知同事你修改的工作集，不管他们是在公共的库还是自己的库里看到变更，提醒他们来复查代码。如果你想要取回修改，你只需要在从远程获取?那些提交，然后发布到本地进行处理。

　　你不需要再担心补丁程序，你拉取的是完整的提交，包括作者、提交数据以及提交日期、提交产生的信息、你所需要的所有数据。这是因为你获取的是你本地代码库的一个扩展，将整个项目贡献和开发者之间的协作流程化了。

　　当你谈论分支的时候，大部分用户都会担心合并所产生的冲突。使用Git是如何避免这些问题的呢？  

　　始终会有产生冲突的潜在可能。如果二个人修改了同一行代码，Git会反馈：“我不知道该怎么办了”，你可以选择：“始终应用我的修改”或“始终应用别人的修改”，但通常你不会这么做，因此Git会处于“不知道该怎么办”的状态，把决定权留给你。这与其它的系统没有分别。这需要用户在某个时刻进行干预，因为计算机是不知道如何处理这一冲突的。这需要人为因素来决定。Git作了一系列优化来简化这一过程。它会将干净的合并产生的修改与其它修改区别开来。

　　Git有索引的概念，它是保存修改的中间层，然后再从那里提交。在中间层的索引将会保存干净的合并，而未合并的修改保留在你的本地，所以你可以用一个命令查看哪些是未合并的修改。因此Git给了你这样一个中间层，让你更容易的处理合并冲突。像其它的许多系统一样，你也可以使用合并工具，但是其实只需要很容易的步骤就可以获得这些修改。Git的另一个优点是因为它以图的结构保留提交，因此能够了解分支的情况，能够完成三路合并。

　　三路合并选择你想要合并的两路分支的端点，以及它们的共同历史点作为上下文。三路合并比试图将两个不同文件匹配起来的两路合并更容易成功。上下文使得算法清晰。Git能够做到是因为它了解历史以及共同的祖先在哪里。

　　你能告诉我们你在GitHub的工作吗？你最近在忙些什么呢？

　　现在我主要负责后端。这是我的日常工作，但从公司的角度看，我的工作是关于如何让人们更容易进行代码协作。这正是我们的主要目标。假设你和我，或者Kenneth和我一起合作于一个项目。我们如何减少编写代码与最终提交到生产系统中间的障碍？而这正是编码工作的意义所在。我的意思是编写代码并最终应用到生产中，即有用的代码。许多系统在这一过程中都会造成阻碍。

　　这种阻碍有可能来自于分支带来的麻烦，或者一个中央服务器失效，?抑或人们制定的种种规则。使用Git，你可以做到说：“这是我的代码，你可以fork一份”。这里的fork意味着你可以在本地获取一份拷贝进行工作。然后，最终整个代码库可以合并回去。但你不需要访问，也不需要从开源社区获取某人的许可来做这件事，你只需要访问站点，获取整个拷贝，它包含了所有的历史，你可以做想要的各种修改。

　　SVN通常是一个封闭的系统，你需要有访问权限，比如只读权限让你可以查看代码，但不能向代码库提交，因为有访问限制。而因为Git让你拥有自己的完整代码库，你可以做想做的一切。这只取决于你发送代码的对象，由他来决定“这些代码靠谱吗”，都有可能。

　　他们是在自己的沙盒里进行操作，这等于给予人们权限说：“放手去做吧，然后展示你的成果”。这意味着人们会真正去修复许许多多的bug，而如果人为设置了障碍人们便不会有这种主动性。就像对人们发出号召说：“看到文档里的小问题了吗？没问题，你可以fork它，做一些小修改，然后提交回来”。这些修改只需要几分钟就能完成，没必要经过整个补丁流程以及邮件列表之类的。而是：“是的，已经改好了，我们就使用它”。也许只是修改几个字。将这些修改发送回列表，只需要一个命令就可以完成合并，整个过程就完成了。使得整个流程更为流畅。这正是我们所追求的——提供更好的工作使得协作流程和将代码提交回主线越简单越好。

　　Kenneth，你使用GitHub集成了许多源代码。你能告诉我们它是如何工作，如何简化你的集成工作的吗？

　　我可以先说一下背景。我们从1998年起将Erlang OTP作为开源项目。然后我们开始释出tar包源码文件。用户可以获取这个文件然后构建自己的系统。当遇到问题的时候，他们可以向邮件列表发送邮件，说明哪里出了问题或者提供一些代码片断提出建议修改等等，这对于我们来说增加了工作量，我们必须花大力气把这些贡献并入到主线中。

　　我们一直在考虑如何使Erlang更加开放，更加便于来自社区的贡献。起先我们考虑可以有一些开放的或者公共的SVN库，但当听说Git和GitHub之后，我们觉得更加适合。你不需要开放集中的存储库。你只需要把代码放到GitHub上，每个人都可以fork一份自己的拷贝进行修改并通知我们有这样一些建议修改的新代码，需要为加入新的特性并入单独的分支。

　　我们会对该分支进行常规的夜间测试，便于了解新的代码会不会对现有代码造成问题。这大大的解放了我们并且也大大有利于从用户那里得到更多的贡献。

　　那么是否成功获得了更多来自用户的贡献呢？ 

　　是的，多了非常多，也许比以前增加?90%。我们在去年的11月的发布时开始使用GitHub，到今年2月25日的发布之间，我们收到了来自30个贡献者的50个提交。我想在此之前我们每次发布之间大概能收到10个提交。这是很大的进步。

　　你告诉我们分支的时候是拷贝的整个代码库。对于GitHub来说，存储所有这些信息，保证它们任何时间可用以及写入每个用户需要的图结构，难道不是一种挑战吗？ 

　　不完全是。这也是我们尽力想办法的地方——尽力让它可能并且有效。Git本身存储效率是高效的。它可以使用Delta偏移包文件。Git的工作方式实际上是基于快照。在每个给定的时间，你作提交的时候，等于是请求：“现在文件系统是什么样子的？”然后提交命令等于说：“保存一个此时的快照”。你可能会以为由于整个拷贝的原因，每次提交会产生许多重复的存储。但Git比这个要聪明多了。

　　它会理解为“所有的这些快照都是时间上离散的点，但存储文件的方式是基于内容的”。如果一次提交到下次之间，文件没有发生改变，它不会存储任何东西。这些提交都指向同一个真实存储的文件。这是获得良好的存储压缩的一种方式。另一个办法是如果你有一系列这些(“不确定对象”——通常指这些代表内容和目录结构的文件)，你可以使用一些高级的压缩以及Delta偏移技术将它们打包成一个大的文件。

　　Git是由一群Linux内核高手们所开发的，他们喜欢文件系统，Git基本上是一个文件系统。他们知道如何做这类工作，使其既快速又高效。讽刺的是，使用Git检出一个代码库和所有历史通常比一个版本的SVN的代码库都要小得多。因为许多版本元数据分散在.svn目录里，许多东西都放在这个目录下。你得往这个目录里塞东西，而使用Git，你所需要的文件都检出了，不管是在哪个提交点，而在根目录的单一的.git目录包含了所有的压缩存储。

　　在开发Git的时候，他们花了很多心思考虑如何高效地存储，因为它是为Linux内核项目开发，这是一个庞大而有着悠久历史的项目。如果它能工作于Linux内核项目，那么它也能工作于大多数项目。这也对于我们是有帮助的，因为它产生了我们必须拥有的文件存储量。从技术的角度来讲，Git处理了大多数会给我们带来麻烦的问题。这就是我们处理存储问题的方式，我们可以尽可能稳定尽可能快的构建，并且每个月都可以改进。

　　将GitHub引入公司初看起来会非常奇怪。我的所有代码库都是公开的。将GitHub引入公司会很困难吗？ 

　　不，对我们而言不是这样。因为我们发布开源软件并不是代表爱立信。因此我们有更多的自由与外部合作。在内部我们使用ClearCase这样的商业软件十多年了，当我们引入Git的时候，我们有个人专门写脚本来在ClearCase与Git之间互相导入，我们正在改善这一情况。现在我们在ClearCase与Git上开展工作，我们致力于在未来的发布中逐渐舍弃ClearCase。

　　我们同时使用Git是因为内部工作也会因此容易得多。虽然现在ClearCase现在支持变更集了，我们也没有使用这个功能。我们为独立的文件进行版本控制，通过Git的变更集带来了许多好处。我们吸纳贡献的代码以及测试，如果发现了问题将数据还原也是易如手掌的事。

　　GitHub有许多用户。

　　现在有22万。

　　对于处理这么大的流量，你们有遇到过什么问题吗？

　　这是一个挑战。通常有可能会发生一些极端的情况，也许有用户做了一些我们原本未计划到的事，而使服务器反应变慢或者产生其它的稳定性问题。从技术上来说这是一个非常困难的问题，这是许多互联网公司不会碰到的情况。大部分公司不会产生这么多需要大量交互的代码库提交。我们开发了一些解决这类问题的技术。

　　随着我们的发展，必须解决各种新的问题，但我们开发了一些新的方式来以更低的成本解决这些问题。我们是创业小?公司，并没有外部的投资。我们很享受这一点，享受因此而带来的自由和因此而来的成长曲线。但这也意味着我们必须要聪明的处理一些问题。有的公司可能是“我们需要使用磁盘存储一些内容并使用web接口访问，花五百万买文件服务器吧。”我们可不能这样。

　　我们采取了一些更聪明的办法开发了一些新的技术，事实上我们使用elrang来做到的。我本人重度使用erlang。我们使用erlang来让前端与后端交互并且每个层次都能够独立的伸缩。因此在web层面和文件层面之间构建的erlang基础设施允许按我们所需进行伸缩。

　　将Erlang托管到GitHub会有什么样的影响，你是如何计划的？

　　当然，我们还是刚刚开始，我们需要学习如何有效的接纳来自用户贡献的代码，我们需要提供关于如何贡献代码的更好的指南和原则。我们还会提供更多的测试套件，有助于我们测试接纳的代码以及帮助贡献者进行测试。我们还计划与我们开发中的新网站进行连接，更好的处理各种建议，新特性和改进提案，在一个新的Git库进行这些开放会给用户带来便利。

　　这些基于文本的描述方案已经有了版本控制机制，你也可以将它们转换为更易读的HTML格式。比如如果你使用mark down格式的话，GitHub是可以支持的。还有一些其它的计划，之前我还提到了我们将全面使用Git，在我们的外部和内部项目都将只使用Git。

　　我听说有的公司不仅将Git用于代码，还用于文件管理等等其它的方面。GitHub的用户将Git用于哪些方面呢？ 

　　这些方面他们都有使用，任何基于文本的方面都可能。最近有人在twitter上分享了他们存放在GitHub上的菜谱。我觉得这太酷了。如果你有一些抄在纸上的菜谱，还需要装在信封里，最终不小心遗失了，那是很可惜的。如果能花点时间把这些整理成文本文件存放在GitHub上，就可以相互分享，也不会遗失。如果有人要对菜谱修改，比如“我认为放三匙黄油比只放二匙要好”，你可以到GitHub上进行修改。

　　能够查看版本修改历史是很酷的，比如菜谱的演变过程。还有很多方面也适用这一场景。我们打算在未来支持各种各样的文件类型。比如以智能的方式展示PDF文件或word文件的修改变更等等。最近我们增加了一个新特性是展示并行的图片变化。当你查看一个提交时，你能查看到旧版本的图片和新版本的图片的变化。

　　你可以一边对照，一边检查。“啊，原来是这里改变了。”通常你一次只能查看一份，而要在本地翻来覆去查看会很麻烦。我们有许多这些的内部开发的特性想要增加，并提供对各种文档的支持。

　　作为开发者，有没有GitHub基础存储等API提供呢？ 

　　当然。你可以访问http://develop.github.com，你会看到整个API文档。用户已经使用它来完成各种任务，比如用它来访问我们提供的问题跟踪系统并在本地展示。有的人通过API实现了命令行的问题跟踪系统，可以通过命令行来打开或关闭问题。今天还有一名用户展示了非常酷的应用。将GitHub上的人之间的关系可视化。GitHub上的用户可以关注其它的用户。

　　这意味着他们可以获得其它用户状态更新的信息流。但你可以将这些信息制成图表，以展示“这些用户与这些用户建立了关系”并通过地理信息来展示，比如展示来自美国、日本、德国或巴西的用户。你可以图形化这些信息，并得到所有GitHub用户、社区关系、社区如何地理分散以及它们如何交互等等的一系列可视化展示。这非常酷。

　　我不知道访问的URL是什么，但是你搜索"GitHub用户可视化图”你就能找到。它上了今天的Hacker News，虽然它不会加入未来的用户。你能找到它。这个图形化非常棒。利用API你可以做到这一切。找到用户，获取关注者列表，跟着找下去，最后拼成一副大图。

　　如果我正在开发菜谱或者别的什么web应用，我只想使用GitHub来简单地存储数据，可以做到吗?有这样的API吗？ 

　　现在做起来可能有点复杂，也许用不到什么API。你只需要说：“这是我创建的存储库，我只想将它作为某种存储机制使用，这种情况下，可能不是最佳的选择，尽管我们有计划基于GitHub的平台之上开发相应的应用，你可以通过注册并在这层接口添加部件应用而构建整个功能。它可以为你提供各种支持，比如持续集成、部署展示等等，只需要在你代码相应的地方和用户接口相应的地方添加就可以。

　　GitHub已经帮你看管了代码和相应的部分，当然如果都查看其它类型的事件或是其它类型的控制能力会更好。如果你想构建自己的应用层，我们可以提供良好的菜谱接口，能让你定制特定类型文件的视图。你也可以自己实现它。这种情况人们只是使用我们的基础设施，但是构建在平台层次之上的一个层次。这是我们将来要致力于做的事情，现在的话你仍需要很明确你在做什么。

　　你提到GitHub使用了Erlang，可以向我们介绍下你是如何利用Erlang解决相应的问题，Erlang在哪些方面提供了帮助吗？ 

　　我们需要做出决策的是哪些是用Ruby和Ruby on Rails写成的。我们使用的是共享文件系统，Red Hat GFS，这并不是非常匹配。我们安装的Red Hat GFS搭建的时候有一些问题，只有一些节点连接到了共享文件存储。他们想要迁移到联合策略，你可以利用一些分散的文件系统，用户通过用户名联合到这些文件服务器上。 

　　我们有一个单独的web层处理Rails响应和执行长期运行的任务。问题在于Rails应用如何在没有更多关于用户位置的信息下获取Git存储的相关信息。这需要是自动获取的。在架构中我们决定加一个代理。我们使用了一个叫Grit的包，这是我和Scott所写的一个Ruby Git绑定。我们想要将它分成两部分：一部分运行Rails，一部分运行于文件服务器上，中间有一个简单的代理，就像桩模式一样。 

　　不管是类还是方法，将会被转换成目标服务器上的远程方法调用。这是第一步，第二步是一旦知道了用户是谁，如何确定用户所在的文件服务器？我们决定在中间加一个代理拦截请求，对其解码，通过用户名来查找路由表(我们使用Redis，Redis是一个非常快的持久的键值存储)，获取用户名和对应的目标地址。

　　这个代理是透明的。Erlang作为服务端。服务器上有一个项目叫Ernie是我写的，这是为一个特殊的协议BERT开发的RPC服务器，这个BERT协议是我自己创建的二进制Erlang术语。它是一个简单的RPC包结构，有一层特殊的RPC协议。Ernie接收BERT RPC请求比如"执行这个Git命令并返回数据”。当请求进来的时候，被发送给Ruby处理器，然后一系列的Ruby进程产生了Erlang服务进程。因为我们想要复用后端获取存储库信息的Ruby代码。 

　　Erlang服务器(因为Erlang的长处在于写服务器，?所以是用Erlang写就的)产生并维护一组Ruby进程来真正的与Git存储库通信。每个请求通过负载平衡分配到这些Ruby处理器上，完成任务，返回数据，转变成BERT RPC响应然后交给前端等待的Grit，Grit收到(通常是二进制信息)然后解析它并完成Rails层需要做的任务。这就是整个流程，Erlang是分发这些请求的工具。

　　我们每天都有成百上千万的RPC请求。我们需要真正坚如磐石那样可靠而又易于编写的服务。Erlang使得这一工作变得非常简单，我不会使用其它任何语言来写这样的服务器，Erlang是最佳的选择。

　　你将所有的Erlang源代码放在了GitHub上，GitHub本身也使用Erlang。你出于什么原因选择了GitHub呢？

　　是的。我想我们一开始是因为他们使用Erlang而产生兴趣开始接触的。他们也到斯德哥尔摩来访问过。

　　是的。我们到斯德哥尔摩参加Erlang用户大会，与他们见了面并进行了一些演示。

　　我想正是那一天我们决定了将Erlang代码托管到GitHub。也可能是其它任何的Git存储。使用GitHub作为Erlang的源代码发布还有一个好处是这也驱动我们将更多其它的Erlang产品托管到GitHub。GitHub有可能成为主要的Erlang开源项目托管服务。

　　通常的情况是，一个框架的版本控制系统选择会造成使用该框架写成或使用该框架的项目也使用同样的版本控制系统，这样利于基于技术选型形成一个生态系统。这很常见，我们也乐于见到。更多的项目聚集在GitHub会形成一个更广泛的社区，而每个人使用起来都会更加方便。

　　我想如果许多项目都是以同一种方式托管的话，用户之间交流起来会更容易。你知道如何处理以及如何贡献代码等等。

　　整个流程成为了一个标准。选择一个系统，围绕这个系统打造一个社区，每个人都遵循同样的流程，整个事情就变得简单多了。我们很乐意帮助实现整个过程。

　　看起来GitHub是托管Erlang源代码的自然之选，还有什么其它的社区表示了这样的兴趣呢？ 

　　都有。我们是从Ruby开始的，因为我们来自Ruby社区，所以占了非常大的比例。几乎所有主流的JavaScript框架现在都迁移到了GitHub，所以JavaScript也占了很大比例。还有的人把CPAN、Perl的代码库搬了过来，建立了GitPAN，几乎涵盖了CPAN的每个项目的tar文件。

　　你可以按顺序取得它们并提交到Git存储，重新创建历史——仅管只是发布历史，把每个项目的历史都放在GitHub上。现在大概有来自CPAN的20000个Perl代码库，人们可以查看它们的演变历史，这在以前是做不到的。你只能把每个tar包都下载下来查看。这对于Perl社区来说是件大好事。

　　我想这帮助很多人能更方便的将Perl代码托管到GitHub上。Python社区和Erlang社区也加入了，接着还有Java和Scala，任何一个写代码而又需要一种简单的协作方式的人都可以用。他们在寻找这种解决方案?，而我们希望他们最终选择GitHub，因为这是能帮助他们简化这一工作的最好方式。

　　你可以在GitHub搜索语言，Erlang提示为第17位流行的语言。你们是如何计算和更新这一数据的呢？我如何得到一个更高的提名？

　　这是通过基于文件名扫描每个项目来计算的，我们查看文件有多大kb，基于扩展名以及项目里的.erl文件，并与其它的代码比较，比如链接的驱动里的C文件。得出结论：“这个项目是由80%的Erlang代码，5%的C代码以及一些Shell代码构成的”。每个项目都做了这样的分析，为每个项目得出一个图表，你可以查看这些图表。我们查看这些数据并且将代码库分门别类。我们也会排除一些主流的框架，比如JQuery，因为许多web项目都会包含JQuery。有时候可能并不是完全准确因为关于代码的重用很难衡量。JavaScript如此高的原因可能是因为人们在许多项目里都会使用JavaScript而我们并不是一直都知道。虽然会有些差别，但这会告诉你一个概况。如果你想要Erlang排名更高的话，你需要整个站点从整体上在更多的项目里包括.erl文件，这是计算排名的方式。

　　我知道我们有.py文件，但不是Python程序。

　　现在是有一点问题，因为是基于文件扩展名的，因为这很容易也很快捷。未来我们会优化这一部分。我们可能会有某种启发式的方式来发现真正的文件内容，比如：“这个文件不是Python，可能是Erlang文件，因为它也有以这种扩展名结尾的文件类型。”，现在我们还不能做得这么精密，但未来我们会花时间来做，如果真的有问题，我们会改善的，最终会达到这一效果。

　　这种文件并不太多，所以还不算什么问题。

　　你提到查看文件内容。让用户来选择将它们合并到特定的语言怎么样？通常这种情况下会掌握更多的语言相关的信息，也更方便合并。我知道在Erlang中有这个方法，其它的也是，所以我不用分析代码，语言本身就提供了这种更易合并的功能。有没有这方面的计划呢？ 

　　现在还没有。这种基于内容或方法或者文件语义的复杂度暂时还没有的。这可以是Git的功能。如果有人确实对某种语言有这方面的贡献，可以提交到Git的邮件列表说“我这里有一种很酷的探测文件结构和更智能的进行合并的方法”，人们可以下载安装并使用这种功能。

　　这样的功能是可能的，只需要有人发起。Git是一个开源项目，任何人都可以对其作出贡献，如果你开发的功能质量可靠而且又有很多人用，那么最终可以合并到核心代码中。

　　你们是否有计划增强GitHub的可视化呢，比如比较两个文件的时候？还有哪些功能计划添加到GitHub呢？ 

　　关于这方面有很多可视化?功能。有一个叫作网络图的功能将会以可视化的方式展示所有的提交。你可以fork一个项目获得一个拷贝。一旦你对该代码库作了独特的提交，比如变更了email并想提交到主线中，你可以将这些变更推送到你fork的分支。这也会在网络图中展示出来。我相信它可以告诉你分支来自于哪一次的提交。

　　渐渐这些存储库会积累起来，“这是主干，这是某个人的分支，这又是另一个人的分支”，我们有很多这样的情况，也有很多图结构。我正把网络图从Flash换成了Canvas。现在对于Linux的支持更友好了，而原来的Flash插件在Linux下是不太支持的。随着时间的发巨爵，我们想要改进现有的可视化工具。我们最近发布了比较，能够比较一系列的提交。

　　你可以这样查看，“展示给我从提交A到提交B发生变更的所有文件，并生成一个综合的diff文件，允许人们评论。最终这会成为一个新的pull请求系统，pull请求是开发人员fork项目之后，向项目所有者发起请求“这是我们的修改，你可以查看是否可以合并进主干，现在已经是准备合并的状态了。”我们将这一流程重建了，现在可以这么做“这是比较视图，将其转化成pull请求”。

　　现在你在网站有了一个优秀的工具来帮助你以一个修改集来整体进行讨论，同时可以严格的定义修改集的起始。我们始终在找寻让流程更平滑的办法。现在所集成的问题(issue)功能，以及问题跟踪功能(你可以在两者中的任一个进行评论，两者都会反映出来)。你可以就此展开讨论，还可以复制一段代码片段进行讨论。 

　　这些评论会做为内嵌的注释在比较视图文件中反映出来。还有各种各样的技巧来让写代码变得更容易。我们正在开发一个代码评审的功能，来让它更进一步，对于如何接收提交和对于pull请求进行更好的讨论，可以形成一个工作流。 

　　你认为这些功能，举例来说，可以让我们接收到提交的时候，能够进行评论并对提交者建议修改，我们能使用这些功能吗？

　　是的。正是如此。这是自成一体的——一个pull request在网站是完整的一页，你可以跟踪它们。它们会被列出来，你总是可以知道是哪些特定的变更集产生了这一系列的提交。这能够帮助人们将贡献机制提升到新的高度。现在对于你想要哪些东西合并还显得有点模糊。但是这将成为优秀的应用并支持对特定的代码进行非常广泛的讨论，将整个流程做得更为清晰明确，便于人们管理。你一定会使用它的。