社交网络走进开源项目托管

了解诸如 GitHub 和 BitBucket 这样的站点世界

社交网络所带来的革命性影响同样波及到软件开发界。为支持跨 Internet 的项目协作,涌现出许多服务,特别是在开源软件开发领域。分布式版本控制、例程分叉 (routine forking) 以及拉请求这样的概念在某种程度上改变着组开发的基本过程。软件协作方面最流行的一个社交网络是 GitHub,其座右铭就是 “社交编码”。在本文中,我们将以 GitHub 为例来了解开发社交网络,但这些原理对其他站点也是相样适用的,比如 BitBucket,甚至也适用于您公司的内部系统。

Uche Ogbuji, 合作伙伴, Zepheira, LLC

Uche Ogbuji 的照片Uche Ogbuji 是 Zepheira 的合作伙伴,主要负责监管复杂 Web 目录和其他丰富上下文数据库的创建。他在高级 Web 技术(比如 XML、语义 Web 和 Web 服务)、开源项目(比如 Akara,一种面向 Web 数据应用程序的开源平台)方面具有多年的开拓经验。他是一位计算机工程师兼作家,出生在尼日利亚,目前生活及工作在美国科罗拉多的博尔德附近。您可以通过他的网络日志 Copia 进一步了解 Ogbuji 先生。



2012 年 6 月 18 日

概述

软件开发人员是社交网络的最早采用者之一,为了解决开发人员,尤其是开源开发人员之间的协作工作而出现社交网络就不足为怪了。一直以来,开源领域都有一些流行的项目托管服务,其中最有名的当属 SourceForge。在很长一段时间,这些服务大部分都构建在 “Web 1.0” 原理之上,虽然许多其他开发项目都对于人们在 Web 上的交互方式进行革新,但是其中有一些都已过时了。

大多数开源项目站点的核心都是集中式源代码管理系统 (SCM),比如 CVS 以及后来的 Subversion。与此同时还出现了新类型的 SCM,称为分布式(或分散式)版本(或修订)控制系统 (DVCS)。DVCS 的核心理念是让您拥有一个有多工作副本的系统而不是只有一个集中的规范源代码树。这就意味着即便多个开发人员偶然连入,他们仍可以就一个项目进行协作。

这些分布式工作副本之间的交互有点像社交网络内人与人之间的交互。因此项目托管站点也就围绕着 DVCS 概念(具有与代码共享模型一致的社交特性)自然而然地发展起来。目前最流行的 DVCS 有 Mercurial、Git 和 Bazaar,而且其中每一个都具有紧密相关的知名服务,分别为 BitBucket、GitHub 和 Launchpad。

在本文中,我们将基于社交网络特性和 DVCS 来了解项目托管站点,重点关注 GitHub。读者应该对版本控制系统有一定了解,但不要求熟知 DVCS。

在 DVCS 上协作的基础知识

当使用 DVCS 进行协作时,第一个用户(我们称她为 Alice)创建了一个代码存储库,然后将其共享给同事 Bob。Alice 也可以在同一台机器上或是用存储磁盘及网络将自己的存储库共享给其他人。Bob 用一个兼容的 DVCS 程序克隆了她的存储库,现在他也有了一个基于 Alice 代码的存储库。Bob 初始的存储库与 Alice 的存储库具有相同的内容,但具有不同的身份和生命周期。而这恰好是 DVCS 和集中式存储库之间的主要区别。

由于新的存储库具有独立的身份和生命周期,克隆一个存储库实际上就是分叉一个项目。之前对于分叉软件项目有一些负面看法,部分是因为有一些广为人知的示例表明分叉与项目内协作的细分有一定关系。Emacs 内的 schism 就是这样一个示例,它是一个享有盛誉的文本编辑器和程序员的实用工具系统。XEmacs 项目因前 Emacs 开发人员的不满而分崩离析。DVCS 已经剔除了分叉的社交上下文,让它成为了协作过程的类属部分。当然,如果 Bob 和 Alice 产生分歧,并决定就此项目各走各路,那么二者虽可能在某时候从分叉着手,但还是很可能会在协作中很自然地使用分叉。

合并变更

具体来说,Bob 和 Alice 可能想要向各自的存储库做各自的更新;也许 Bob 正在处理的是用户界面,而 Alice 则正在研究程序的核心逻辑。某时,他(她)们可能就会想要聚在一起并综合各自的劳动成果。他(她)们在各自的存储库中分别积累了变更集。变更集 是文件更新的一个集合,变更集曾经通过 DVCS 发出的 “commit” 命令注册。

在集中式版本控制系统中,变更集向主存储库提交,并用增量修订号识别。比如,Bob 所做的第一个提交可能是修订版 1.1,第二个可能是 1.2,以此类推。在 DVCS 中则不是这样的,因 DVCS 没有中央存储库,也无法对变更排序进行全局管理,因此每个变更集都被赋予了一个跨存储库惟一的散列 (hash)。图 1 说明了最初的克隆以及 Bob 和 Alice 各自的变更集的进展。图中的星星标示的是 Bob 和 Alice 的存储库状态完全相同的时候(即 Bob 克隆了 Alice 代码的初始副本的时候)。

图 1. 与 DVCS 的初始交换
与 DVCS 的初始交换

若 Bob 和 Alice 想要合并他(她)们的工作成果,可以交换变更集、解决冲突,直至新的存储库能够如他(她)们所愿的那样呈现其工作成果。要启动这个过程,Bob 可以从 Alice 的存储库 “拉” 出变更,反之亦然。同样地,这与以何种方式进行并没有太大关系,完全取决于协作的环境。Bob 和 Alice 之间拉的方向不时地就会更替,有可能一时兴起就更替一次。

合并机制

当 Bob 从 Alice 处拉出时,DVCS 会按顺序将 Alice 的每个变更集应用到 Bob 的本地版本。变更集有可能会导致冲突,比如 Bob 和 Alice 恰巧修改了一个文件内某一处的同一行,又比如 Bob 更新了一个 Alice 已经从其存储库删除的文件。在冲突发生时,DVCS 软件有可能进行一次自动合并,也有可能需要 Bob 的介入来实现合并。

Bob 从 Alice 处拉出变更集后,就可以将合并的结果推向 Alice。DVCS 将从最后的合并点处理 Bob 的变更集,还将识别出有些变更集是 Alice 自身的,并已经应用到 Bob 的存储库。这些惟一的散列是在这个过程内找出变更集身份的关键。当推操作完成时,Alice 和 Bob 的每个存储库内均具有相同的内容。图 2 展示了 pull/merge/push 的过程。请注意这最终会使 Bob 和 Alice 之间出现一个新的共享状态。

图 2. 用 DVCS 合并变更集
用 DVCS 合并变更集

此过程具有很多变数和微妙之处,有些是特定于 DVCS 实现所惟一拥有的,但在这里我只谈及 DVCS 的新用户最常遇到的问题之一。

假设在上述过程中,Bob 在将自己的变更推向 Alice 的存储库之前忘记先拉出 Alice 的变更。在这种情况下,DVCS 软件会通知 Bob 从与 Alice 存储库的最后合并点进行分支。DVCS 的核心原则之一是变更集只应用于存储库点的已知的开始状态,称为公共父。就公共父而言,由于 Bob 的变更集从他第一次从 Alice 处克隆时就存在,DVCS 在独立的分支中应用这些 changesets. ent 之前实际上会倒回到此状态,而这通常并不是 Bob 或 Alice 所想要的。在这种情况下,DVCS 通常会发出一个有关推操作创建 “多头” 的警告。Bob 可以中止推操作,然后从 Alice 处进行拉操作,而这会在他自己的同一个分支上合并进 Alice 的变更集。拉操作的结果就是一个单一的分支,包含了 Bob 和 Alice 来自公共父的变更集。在这种状态下,Bob 就可以在没有 “多头” 问题的情况下推向 Alice。


基本 DVCS 交互的社交蕴意

DVCS 提供了处理过程内的极大灵活性,但项目应在基本用法上添加更宽泛的工作流,尤其是当越来越多具有不同的角色和交互等级的人参与进来时,更应如此。通常,受到认可的存储库开始时也会呈现一些旧的集中式存储库风格,但这只是偶然的。分叉简单、正常,且在对项目感兴趣的人中经常会分散有无数的存储库,而参与者只是按照惯例避免混乱。在允许任何人克隆或从主存储库拉出的开源项目中,情况更是如此。项目主管会标示主存储库,并赋予可信协作者以进行推变更的权限。

拉请求

在一个状态良好的开源项目中,并不是所有的参与者都是可信的协作者。大多数经典的项目托管站点都具有补丁跟踪器与问题跟踪器。任何人都可以向项目提交补丁,这个补丁随后被跟踪,同时由核心开发人员检查这个补丁并与提交者交流来做相应的更改。最终,补丁会被应用到主项目存储库。

DVCS 的本性以及对变更集的周密管理就使得有机会对此过程进行一些改进。具体来说,旧的补丁提交系统经常会丢失特定补丁的变更历史。有了 DVCS,参与者可以从主存储库拉出、在其工作存储库内开发其自己的变更、照常提交,然后提交结果变更集供审查和讨论。这个过程就是拉请求。实际上,就是参与者请求核心开发人员拉出含建议变更的工作存储库,在进行了优化变更的讨论后再将这些变更集推向主存储库。

在像 GitHub 这样的系统中,拉请求特性(参阅 参考资料)是通过一个便捷界面实现的,围绕的是指定一个存储库来启动拉请求、讨论所建议的变更、然后将产生的变更集应用到目标存储库的这样一个工作流。

关注者和流行度

任何一个社交网络都具备关注他人以及关注度比赛的系统。主要的 DVCS 站点也不例外。如果您发现了自己感兴趣的项目,就可以选择关注这个项目的开发人员或这个项目,而开发人员知悉此事并选择了关注您。使用的词汇会有所不同,比如在 GitHub 内,是 “关注” 一个人,“观察” 一个项目,但是这个概念类似于具有相同社交动态的 Twitter 和 Facebook。比如,从关注者的人数多少等就能对某个开发人员的影响度或项目的健康程度有一个印象,而这对覆盖在 DVCS 上的社交动态也是有作用的,比如在一个激烈的分叉中究竟是哪个分支 “胜出”。


结束语

开源软件一直在不断发展,已经成为全球技术界的一个庞大组成部分。这种发展不仅得益于辛勤工作,还有个性和主张。我希望能够这样说,在体现开源协作过程的社交网络中,应该让代码讲话,所有其他的都是次要的。换言之,您不能拿走社交网络的社交部分。如果您参与到像 GitHub 这样的站点,关注您对社交网络的兴趣,不管是作为用户、项目参与者还是项目主管,重要的一点是不仅要了解底层实用工具工作流,还要了解会与比特交换密切相关的社交性弦外音和蕴意。

使用社交网络最常见的建议有:尽量亲自与人交流,有勇气拒绝无价值的个人干扰,而且最重要的是要生成最好的代码来吸引关注者甚至参与者。在大型项目上进行大量协作之前,像 GitHub 这样的站点是您逐渐成长的一个简单起点。我希望本文能对您理解这些新兴项目托管站点有所帮助。

参考资料

学习

获得产品和技术

  • GitHub 是一个流行的项目托管站点,其中代码存储库使用 Git DVCS 进行管理。
  • BitBucket 是一个与 Mercurial DVCS 紧密相关的项目托管站点,并且支持 Git。
  • 获取 IBM 产品评估试用版软件,可以通过下载或从 DVD 获得,使用面向开发人员的软件改进您的下一个开源开发项目。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Open source
ArticleID=821610
ArticleTitle=社交网络走进开源项目托管
publish-date=06182012