《Git版本控制管理(第2版)》——1.2 Git的诞生

1.2 Git的诞生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

免费自由(Be free, as in freedom)
——Nuff曾说过。

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

时间: 2024-09-16 06:50:12

《Git版本控制管理(第2版)》——1.2 Git的诞生的相关文章

《Git版本控制管理(第2版)》——第4章 基本的Git概念 4.1基本概念

第4章 基本的Git概念 4.1 基本概念 前一章介绍了Git的一个典型应用,并且可能引发了相当多的问题.Git是否在每次提交时存储整个文件?.git目录的目的是什么?为什么一个提交ID像乱码?我应该注意它吗? 如果你用过其他VCS,比如SVN或者CVS,那么对最后一章的命令可能会很熟悉.事实上,你对一个现代VCS期望的所有操作和功能,Git都能提供.然而,在一些基本的和意想不到的方面,Git会有所不同. 本章会通过讨论Git的关键架构组成和一些重要概念来探讨Git的不同之处和原因.这里注重基础

《Git版本控制管理(第2版)》——4.3 Git在工作时的概念

4.3 Git在工作时的概念 带着一些原则,来看看所有这些概念和组件是如何在版本库里结合在一起的.让我们创建一个新的版本库,并更详细地检查内部文件和对象库. 4.3.1 进入.git目录首先,使用git init来初始化一个空的版本库,然后运行find来看看都创建了什么文件. $ mkdir /tmp/hello $ cd /tmp/hello $ git init Initialized empty Git repository in /tmp/hello/.git/ # 列出当前目录中的所有

《Git版本控制管理(第2版)》——1.4 时间线

1.4 时间线 有了应用场景,有了一点额外的动力,再加上对新VCS的需求迫在眉睫,Git于2005年4月诞生了. 4月7日,Git从以下提交起,正式成为自托管项目. commit e83c5163316f89bfbde7d9ab23ca2e25604af29 Author: Linus Torvalds <torvalds@ppc970.osdl.org> Date: Thu Apr 7 15:13:13 2005 –0700 Initial revision of "git&quo

《Git版本控制管理(第2版)》——第1章 介绍 1.1背景

第1章 介绍 1.1 背景 现如今,难以想象有创意的人会在没有备份策略的情况下启动一个项目.数据是短暂的,且容易丢失--例如,通过一次错误的代码变更或者一次灾难性的磁盘崩溃.所以说,在整个工作中持续性地备份和存档是非常明智的. 对于文本和代码项目,备份策略通常包括版本控制,或者叫"对变更进行追踪管理".每个开发人员每天都会进行若干个变更.这些持续增长的变更,加在一起可以构成一个版本库,用于项目描述,团队沟通和产品管理.版本控制具有举足轻重的作用,只要定制好工作流和项目目标,版本控制是最

《Git版本控制管理(第2版)》——导读

前言 本书是按照一系列渐进式主题进行组织编排的,每一个主题都建立在之前介绍的概念之上.本书前11章讲解的是与一个版本库相关的概念和操作,这些内容是在多个版本库上进行复杂操作(将在本书后10章涉及)的基础. 如果你已经安装了Git,甚至曾经简单使用过,那么你可能用不到前两章中Git相关的介绍性知识和安装信息,第3章的知识对你来说也是可有可无. 第4章介绍的概念是深入掌握Git对象模型的基础,读者可以通过第4章清楚理解Git更为复杂的操作. 第5章-第11章更为详细地讲解了Git的各个主题.第5章讲

《Git版本控制管理(第2版)》——1.5 名字有何含义

1.5 名字有何含义 据Linus宣称,命名为Git,是因为"我是一个自私的混蛋,我照着自己命名我所有的项目,先是Linux,现在是git"⑤.倘若,Linux这个名字是Linus和Minix的某种结合.那么反用一个表示愚蠢无用之人的英语词汇也不是没可能. 那之后,也有人曾建议,使用一些其他也许更让人舒服的解释.其中最受欢迎的一个就是:全局信息追踪器(Global Information Tracker).

《Git版本控制管理(第2版)》——1.3 先例

1.3 先例 VCS的完整历史已经超出了本书的讨论范围.然而,有一些具有里程碑.革新意义的系统值得一提.这些系统对Git的开发或者有重要的铺垫意义,或者有引导意义.(本节为可选章节,希望能够记录那些新特性出现的时间,以及在自由软件社区变得流行的时间.) 源代码控制系统(Source Code Control System, SCCS)是UNIX②上最初的几个系统之一,由M. J. Rochkind于20世纪70年代早期开发.["The Source Code Control System,&qu

《Git版本控制管理(第2版)》——4.2 对象库图示

4.2 对象库图示 让我们看看Git的对象之间是如何协作来形成完整系统的. blob对象是数据结构的"底端":它什么也不引用而且只被树对象引用.在接下来的图里,每个blob由一个矩形表示. 树对象指向若干blob对象,也可能指向其他树对象.许多不同的提交对象可能指向任何给定的树对象.每个树对象由一个三角形表示. 一个圆圈表示一个提交对象.一个提交对象指向一个特定的树对象,并且这个树对象是由提交对象引入版本库的. 每个标签由一个平行四边形表示.每个标签可以指向最多一个提交对象. 分支不是

分布式版本控制Git分支管理策略及使用规范流程

Git分支管理策略 目前最流行的"版本管理系统",非Git莫属. 相比同类软件,Git有很多优点.其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便.有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用. 但是,太方便了也会产生副作用.如果你不加注意,很可能会留下一个枝节蔓生.四处开放的版本库,到处都是分支,完全看不出主干发展的脉络. Vincent Dr