来自 操作系统 2020-05-07 00:57 的文章
当前位置: 网上澳门金莎娱乐 > 操作系统 > 正文

GitHub将成开源项目贡献代码的福音

图片 1

现如今,难以想象有创意的人会在没有备份策略的情况下启动一个项目。数据是短暂的,且容易丢失—例如,通过一次错误的代码变更或者一次灾难性的磁盘崩溃。所以说,在整个工作中持续性地备份和存档是非常明智的。

开源项目依赖于大众合作。成功的开源项目都有一批活跃的个人和公司在贡献代码,编写文档,测试新功能。不幸的是,由于不同的项目使用不同的bug跟踪系统,版本控制系统,审核系统,使得贡献和提交代码变的不是那么容易。程序包的维护者也由于不能容易的及时处理所有提交上来的补丁程序而使代码贡献者有些灰心。

对于文本和代码项目,备份策略通常包括版本控制,或者叫“对变更进行追踪管理”。每个开发人员每天都会进行若干个变更。这些持续增长的变更,加在一起可以构成一个版本库,用于项目描述,团队沟通和产品管理。版本控制具有举足轻重的作用,只要定制好工作流和项目目标,版本控制是最高效的组织管理方式。

在2005年,Linus Torvalds(Linux之父)为了解决在处理Linux内核上的补丁程序遇到的问题而开发了Git版本控制系统。几年之后,出现了以Git为基础的具有漂亮的web使用界面的GitHub,这使得对这个平台上的项目进行分支操作,打补丁,和提交代码等都变得异常简单容易。它采用的标准化的wiki和问题跟踪系统,这意味着所有的项目是按同一种方式搭建起来的。一旦你学会了如何向GitHub上的一个项目提交代码,你也就知道了如何向其它所有项目提交代码了。

一个可以管理和追踪软件代码或其他类似内容的不同版本的工具,通常称为:版本控制系统,或者源代码管理器,或者修订控制系统,或者其他各种和“修订”、“代码”、“内容”、“版本”、“控制”、“管理”和“系统”等相关的叫法。尽管各个工具的作者和用户常常争论得喋喋不休,但是其实每个工具都出于同样的目的:开发以及维护开发出来的代码、方便读取代码的历史版本、记录所有的修改。在本书中,“版本控制系统”一词就是泛指一切这样的工具。

不幸的是,GitHub把事情变的如此简单,我发现自己都变懒了,我会感觉向非GitHub的项目提交代码太麻烦,你通常需要在他们的自有的bug管理系统上注册,学会提交补丁的流程,长时间的等待提交的补丁被他们采纳。这些额外需要付出的努力有时间就足以阻挡我提交一个补丁包了,这对项目本身也不是个好事。

本书主要介绍Git这款功能强大、灵活而且低开销的VCS,它可以让协同开发成为一种乐趣。Git由Linus Torvalds发明,起初是为了方便管理Linux{![Linux是Linus Torvalds在美国和其他国家的注册商标。—原注]}内核的开发工作。如今,Git已经在大量的项目中得到了非常成功的应用。

对于开源软件和其它一些社团开发的项目来说,简单的代码捐赠流程至关重要(看看维基百科就清楚了)。GitHub在不断的壮大,我相信有更多项目会开始感觉到需要转移它们的宿主平台的压力了,它们会行动的,我等待着。好的软件是大家的福利。

通常来说,当工具跟不上项目需求时,开发人员就会开发一个新的工具。实际上,在软件领域里,创造新工具经常看似简单和诱人。然而,鉴于市面上已经有了相当多的VCS,决定再创造一个却应该是要深思熟虑的。不过,如果有着充分的需求、理性的洞察以及良好的动机,则完全可以创造一个新的VCS。

(责任编辑:admin)

Git就是这样一个VCS。它被它的创造者(Linus,一个脾气急躁又经常爆出冷幽默的人)称作“从地狱来的信息管理工具”。尽管Linux社区内部政治性的争论已经淹没了关于Git诞生的情形和时机的记忆,但是毋庸置疑,这个从烈火中诞生的VCS着实设计优良,能够胜任世界范围内大规模的软件开发工程。

在Git诞生之前,Linux内核开发过程中使用BitKeeper来作为VCS。BitKeeper提供当时的一些开源VCS所不能提供的高级操作。然而,在2005年春天,当BitKeeper的所有方对他们的免费版BitKeeper加入了额外的限制时,Linux社区意识到,使用BitKeeper不再是一个长期可行的解决方案。

Linus本人开始寻找替代品。这次,他回避使用商业解决方案,在自由软件包中寻找。然而,他却发现,在现有的自由软件解决方案中,那些在选择BitKeeper之前曾经发现的,导致他放弃自由软件解决方案的一些限制和缺陷如今依然存在。那么,这些已经存在的VCS到底存在什么缺陷?Linus没能在现有VCS中找到的有关特性到底是哪些?让我们来看看。

分布式开发有很多方面,Linus希望有一个新的VCS能够尽可能覆盖这些方面。它必须允许并行开发,各人可以在自己的版本库中独立且同时地开发,而不需要与一个中心版本库时刻同步(因为这样会造成开发瓶颈)。它必须允许许多开发人员在不同的地方,甚至是离线的情况下,无障碍地开发,

仅仅支持分布式开发模型还是不够的。Linus深知,每个Linux版本都凝聚了数以千计开发人员的心血。所以新的VCS必须能够很好地支持非常多的开发人员,无论这些开发人员工作在整个项目相同还是不同的部分。当然,新的VCS也必须能够可靠地将这些工作整合起来。

Linus决心要确保新的VCS能够快速并且高效地执行。为了支持Linux内核开发中大量的更新操作,他知道不管是个人的更新操作,还是网络传输操作,都需要保证执行速度。为了节约存储空间,从而节约传输时间,需要使用“压缩”和“差异比较”技术。另外,使用分布式开发模型,而非集中式模型,同样也确保了网络的不确定因素不会影响到日常开发的效率。

因为Git是一个分布式版本控制系统,所以非常需要能够绝对保证数据的完整性和不会被意外修改。那如何确定,在从一个开发人员到另一个开发人员的过程中,或者从一个版本库到另一个版本库的过程中,数据没有被意外修改呢?又如何确定版本库中的实际数据就是认为的那样?

Git使用一个叫做“安全散列函数”的通用加密散列函数,来命名和识别数据库中的对象。虽然也许理论上不是绝对的,但是在实践中,已经证实这是足够可靠的方式。

版本控制系统的一个关键方面,就包括能够定位谁改动了文件,甚至改动的原因。Git对每一个有文件改动的提交(Git把一个历史版本叫做一个“提交”)强制使用“改动日志”。“改动日志”中存储的信息由开发人员、项目需求、管理策略等决定。Git确保被VCS管理的文件不会被莫名地修改,因为Git可以对所有的改动进行责任追踪。

Git版本库中存储的数据对象均为不可变的。这意味着,一旦创建数据对象并把它们存放到数据库中,它们便不可修改。当然,它们可以重新创建,但是重新创建只是产生新的数据对象,原始数据对象并不会被替换。Git数据库的设计同时也意味着存储在版本数据库中的整个历史也是不可变的。使用不可变的对象有诸多优势,包括快速比较相同性。

有了原子事务,可以让一系列不同但是相关的操作要么全部执行要么一个都不执行。这个特性可以确保在进行更新或者提交操作时,版本数据库不会陷入部分改变或者破损的状态。Git通过记录完整、离散的版本库状态来实现原子事务。而这些版本库状态都无法再分解成更小的独立状态。

几乎所有的VCS都支持在同一个项目中存在多个“支线”。例如,代码变更的一条支线叫做“开发”,而同时又存在另一条支线叫做“测试”。每个VCS同样可以将一条支线分叉为多条支线,在以后再将差异化后的支线合并。就像大多数VCS一样,Git把这样的支线叫做“分支”,并且给每个分支都命名。

伴随着分支的就是合并。Linus 不仅希望通过简单的分支功能来促进丰富的开发分支,还希望这些分支的合并可以变得简单容易。因为通常来说,分支的合并是各VCS使用中最为困难和痛苦的操作,所以,能够提供一个简单、清晰、快速的合并功能,是非常必要的。

为了让各个开发人员不需要查询中心服务器就可以得到历史修订信息,每个人的版本库中都有一份关于每个文件的完整历史修订信息就非常重要。

即使最终用户也许并不关心是否有一个清晰的内部设计,对于Linus以及其他Git开发人员来说,这确实非常重要。Git的对象模型拥有者简单的结构,并且能够保存原始数据最基本的部分和目录结构,能够记录变更内容等。再将这个对象模型和全局唯一标识符技术相结合,便可以得到一个用于分布式开发环境中的清晰数据对象。

—Nuff曾说过。

有了创造一个新VCS的清晰理由后,许多天才软件工程师一起创作出了Git。需求是创新之母!

VCS的完整历史已经超出了本书的讨论范围。然而,有一些具有里程碑、革新意义的系统值得一提。这些系统对Git的开发或者有重要的铺垫意义,或者有引导意义。(本节为可选章节,希望能够记录那些新特性出现的时间,以及在自由软件社区变得流行的时间。)

源代码控制系统(Source Code Control System, SCCS)是UNIX{![UNIX是Open Group在美国和其他国家的注册商标。—原注]}上最初的几个系统之一,由M. J. Rochkind于20世纪70年代早期开发。[“The Source Code Control System,” IEEE Transactions on Software Engineering 1: 364-370.]这是有证可查的可以运行在UNIX系统上的最早的VCS。

SCCS提供的数据存储中心称为“版本库”(repository),而这个基本概念一直沿用至今。SCCS同样提供了一个简单的锁模型来保证开发过程有序。如果一个开发人员需要运行或者测试一个程序,他需要将该程序解锁并检出。然而,如果他想修改某个文件,他则需要锁定并检出(通过UNIX文件系统执行的转换)。当编辑完成以后,他又可以将文件检入到版本库中并解锁它。

修订控制系统(Revision Control System,RCS)由Walter F. Tichy于20世纪80年代早期引入[“RCS: A System for Version Control,”Software Practice and Experience 15: 637-654.]。RCS引入了双向差异的概念,来提高文件不同版本的存储效率。

并行版本系统(Concurrent Version System,CVS)由Dick Grune于1986年设计并最初实现。4年后又被Berliner和他的团队融入RCS模型重新实现,这次实现非常成功。CVS变得非常流行,并且成为开源社(http:www.opensource.org)区许多年的事实标准。CVS相对RCS有多项优势,包括分布式开发和版本库范围内对整个“模块”的更改集。

此外,CVS引入了一个关于“锁”的新范式。而之前的系统需要开发人员在修改某个文件之前先锁定它,一个文件同时只允许一个开发人员进行修改,所有需要修改这个文件的开发人员需要有序等候。CVS给予每个开发人员对于自己的私有版本写的权限。因此,不同开发人员的改动可以自动合并,除非两个开发人员尝试修改同一行。如果出现修改同一行的情况,那这一行将会作为“冲突”被标记出来,由开发人员手动去解决。这个关于“锁”的新规则使得多个开发人员可以并行地编写代码。

就像经常发生的那样,对CVS短处和缺点的改进,促进了新VCS的诞生:Subversion。SVN于2001年问世,迅速风靡了开源社区。不像CVS,SVN以原子方式提交改动部分,并且更好地支持分支。

BitKeeper和Mercurial则彻底抛弃了上述所有解决方案。它们淘汰了中心版本库的概念,取而代之的,数据的存储是分布式的,每个开发人员都拥有自己可共享的版本库副本。Git则是从这种端点对端点(Peer to Peer)的模型继承而来。

最后,Mercurial和Monotone首创了用散列指纹来唯一标识文件的内容,而文件名只是个“绰号”,旨在方便用户操作,再没有别的作用。Git沿用了这个概念。从内部实现上来说,Git的文件标识符基于文件的内容,这是一个叫做“内容可寻址文件存储”(Content Addressable File Store,CAFS)的概念。这不是一个新概念。[见“The Venti Filesystem,” , Bell Labs, http://www.usenix.org/events/fast02/quinlan/quinlan_html/index.html.] 据Linus的说法{![私人电子邮件。—原注]}, Git直接从Monotone借用了这个概念。Mercurial也同时实现了这个概念。

本文由网上澳门金莎娱乐发布于操作系统,转载请注明出处:GitHub将成开源项目贡献代码的福音

关键词: