《Pro Git》阅读随想

  之前做版本管理,我使用最多的是SVN,而且也只是在用一些最常用的操作。最近公司里很多项目都开始上Git,借这个机会,我计划好好学习一下Git的操作和原理,以及蕴含在其中的设计思想。同事推荐了一本《Pro Git》,读起来感觉很好,在这里分享下阅读时的思考。此书的在线阅读地址:http://iissnan.com/progit/

 


 

第一章 起步

  这一章介绍了Git的相关历史和基本特点,以及安装配置方法。这里提到的Git的特点包括“直接记录快照,而非差异比较”、“近乎所有操作都是本地执行”、“时刻保持数据完整性”、“多数操作仅添加数据”、“文件的三种状态”,除了最后一点我会放在下一章里梳理,下面会对其中一部分进行一些思考的分享。

直接记录快照,而非差异比较

Git 和其他版本控制系统的主要差别在于,Git 只关心文件数据的整体是否发生变化,而大多数其他系统则只关心文件内容的具体差异。

  这个策略要求Git记录每个版本的完整文件。如果需要对比同一个文件的两个连续版本间差异,Git会直接比较两个文件,而其他系统可以直接把保存的具体差异取出来;但是如果比较间隔版本的文件,后者需要将差异全部合并,才能显示。这意味着版本的间隔越多,基于差异的系统在比较差异所需要的计算量会越大,而Git完全不会受到这个影响。

  可以把这个策略看作是空间换时间的实践。现在单位存储空间的费用越来越低,TB级硬盘也已沦为白菜价,即使是开发人员使用的百兆级SSD也已经普及,额外的空间消耗完全可以不做考虑。

 

时刻保持数据完整性

在保存到 Git 之前,所有数据都要进行内容的校验和(checksum)计算,并将此结果作为数据的唯一标识和索引。换句话说,不可能在你修改了文件或目录之后,Git 一无所知。这项特性作为 Git 的设计哲学,建在整体架构的最底层。所以如果文件在传输时变得不完整,或者磁盘损坏导致文件数据缺失,Git 都能立即察觉。

Git 使用 SHA-1 算法计算数据的校验和,通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值,作为指纹字符串。该字串由 40 个十六进制字符(0-9 及 a-f)组成,看起来就像是:

24b9da6552252987aa493b52f8696cd6d3b00373

 

Git 的工作完全依赖于这类指纹字串,所以你会经常看到这样的哈希值。实际上,所有保存在 Git 数据库中的东西都是用此哈希值来作索引的,而不是靠文件名

  使用SHA-1产生的hash值而不是文件名做索引的好处是,hash值的长度固定,并且随机性很好,符合哈希充分散列的要求。SHA-1本身就是一种常用的hash函数,其应用不在这里重述。前一段时间Google宣布“将在Chrome浏览器中逐渐降低SHA-1证书的安全指示”,但它这样做的原因是出于安全考虑,并不意味着Git使用SHA-1做hash函数不合适,有兴趣的读者可以看看相关的分析,如:深度:为什么Google急着杀死加密算法SHA-1

  文件名做索引有什么坏处呢?长度不固定并不是主要的问题。以用maven管理的代码为例,如果依赖比较复杂,那么各个package中都有各自的pom.xml,它们的文件名是完全一样的,会导致严重的hash碰撞。


 

第二章 Git基础

  这章介绍了最基本的 Git 本地操作:创建和克隆仓库,做出修改,暂存并提交这些修改,以及查看所有历史修改记录。这些操作的命令不再一一列出,来看看第一章提到但没有详细讲述的文件状态。

文件状态

   梳理一下文件各个状态的转换过程和逻辑,可以画出下面的图示。在这张图中,常用的本地的文件操作命令以及将会导致的状态变更就很清楚了:

  除了文件状态,简单说下Git里标签的意义。众所周知,SVN里每个版本都是有版本号的,从1开始,每次提交都会升高。而在Git中,每次提交只会返回一个SHA-1 校验和其他的信息,是没有版本号的。

  发布时,如何指定Git上的代码版本?这时就可以用tag来做标记了。tag相当于为一个特定的版本增加的标记,可以替代SVN里版本号的功能,而且更强大。

 


 

第三章 Git分支

用链表组织分支

   如果要理解Git,要理解Git的分支;如果要理解Git的分支,首先要理解Git中的四个基本的对象模型:blob、tree、commit、tag。这部分原书写的比较简单,具体可以参考《Git Community Book》第一章。幸运的是,该书也有网络版,这一部分内容的地址是:http://gitbook.liuhui998.com/1_2.html。简单地说,这四种对象分别对应于:

  •   blob:表示文件内容,是指向文件的索引。
  •   tree:表示目录层级关系,保存了其他blob对象和tree对象的指针。
  •   commit:保存一次提交的信息,以及一个tree对象根目录。
  •   tag:标记一次commit。

  分支是把commit对象组织成了链表的形式,不同的分支指向了对应的commit对象,每次在分支上提交,都会在链表表头上插入新的对象,如下图上的master和testing两个分支,图中的绿色方框代表一个commit对象。此时可以通过控制HEAD指针所在位置来指明使用了哪个分支。

  简单回忆下链表的相关操作可以发现,只要保存各个分支对应的表头,我们可以很容易的通过给HEAD赋值在各个分支之间切换。同时对于每次提交,链表插入的操作也很简单。

  在理解了Git版本管理的链表式的实现方式之后,只要具有基本的算法知识,其他操作原理的理解会变得非常迅速。以下各图来自于《Pro Git》。

  1.从master拉新分支iss53,只需新增该分支的指针,未做修改后的提交时,iss53指向master。提交新内容时,创建对应commit对象,iss53指针前移。

 

  2.当分支hotfix的祖先节点中包括master分支,将hotfix分支merge回master分支,只需要把master的指针移动hotfix上,没有任何文件处理工作,因而称之为Fast forward。

 

  3.当分支iss53合并回master分支,但是master不是iss53的祖先时,先计算二者的最近一个的公共祖先,把它和这两个分支的commit进行合并计算,创建新的commit对象。这个对象有两个祖先。如果合并时遇到冲突,不会提交,而是等人工处理完冲突并git add后才能进行提交。

  如何寻找交叉链表的第一个公共节点?这是一个常见算法问题,可以参考旧作《编程之美》3.6判断链表是否相交之扩展:链表找环方法证明的扩展问题2。

  4.(个人推测)查看某个分支是否已合并到master分支:比较两个分支指针是否指向同一个对象。

  5.(个人推测)删除已合并master的分支:直接删除该分支的指针;删除未合并的分支(git branch -d XXX):删除该分支不在master上所有commit对象及相关的对象、删除分支指针。

 

merge还是rebase?

  merge是直接将两个分支合并到一起:创建一个合并后的commit节点,祖先有两个,是被合并的两个分支A和分支B,节点内容是三方(分支A、分支B、分支A和B的共有最近祖先)合并的结果。原有的链表上的节点保留,分支上的提交历史没有发生改变。如下图(来自《Pro Git》)所示:

  rebase则是将一个分支A中的内容产生的补丁在另一个分支B上重新打一遍,打完之后,分支A的节点变成了分支B的后继。rebase完成后,分支A的特有节点发生了变动。如下图(来自《Pro Git》)所示,C3和C3`是不同的节点:

  实际上,merge和rebase产生的节点的内容上是一样的,发生冲突时仍需要人工解决,不同点只是提交的历史节点。rebase更适用于未公开提交(可以理解为push到远程仓库)的对象,清理提交历史;如果对已公开的提交对象rebase,并且已经有人对这些已提交对象开展了后续开发,会使得提交历史非常混乱。详细的例子可以查看原书“分支的衍合”一节。


 

第六章 Git工具

  在“使用Git调试”一节,提到了git bisect进行各个commit的二分查找。众所周知,单链表本身是不支持二分查找的,推测Git可能使用了以下两种方式支持:

  (1)将起始和结束的两个commit中间所有节点的指针保存到一个临时数组中,二分查找基于这个临时数组进行;

  (2)git使用的了类似于跳表的链表。跳表可参考http://www.cnblogs.com/liuhao/archive/2012/07/26/2610218.html。

  进一步地推测,在进行二分查找时,对commit进行修改,可能会导致查询错误。


 

第九章 Git内部原理

底层命令究竟做了些什么

  在第一次阅读这一章时,我从第二节开始就有点晕头转向,不知道究竟行文的思路是什么。第二次阅读时才有点眉目,并发觉第一次没看懂的原因是,原文很多地方只是描述底层命令执行后发生的现象,并没有完整地告诉读者这个命令执行的结果。网上很多对git的介绍文章偏实用主义,对这些底层命令并没有花费多少笔墨。好在git自身的文档很完善,git -help <command>对底层命令也有效,可以自行查看。不过方便起见,这里会简单介绍下这些底层命令。以下介绍底层命令时,实际用法为git XXX,如git hash-object,简记为hash-object。

  当然,这里的介绍不是文档的翻译,其中也加入了一些个人的理解,因此,各个命令的介绍可能有少量的连续性。

  另外一个有趣的事实:Git高层命令是可以自动补全的,而底层命令不行。

hash-object

  计算一个文件(可以通过--stdin指定为从标准输入读取)的对象ID,这个对象ID实际上是git这个内容寻址文件系统的K-V关系的键值。可以使用-w选项将该对象添加到git的文件对象库,而不仅仅是把对象的键值显示在屏幕上。

 

cat-file

  显示git对象的内容或类型,需要指定对象ID。-p用于输出格式化内容。你会发现,通过hash-object生成的文件直接打开是乱码,想要查看原始内容,必须用git cat-file。可以推测,git对象中不仅保存了文件内容,还应该保存了结构信息等,并有被压缩的可能。这节的结尾便证实了这点:先写文件头(包括文件类型和内容长度)、内容正文,再计算SHA-1校验和(作为文件路径和文件名,不参与文件本身的保存),最后进行压缩。

  如果对一个tree对象使用cat-file -p,可以看到这个tree对象包括了其他tree或blob对象的引用(同样是对象ID)。

update-index

  为文件创建或更新index。这样做会导致文件被放入暂存区域(回想下git中文件的staged状态)。运行这个命令之后,往往接下来要运行git write-tree。对同一个文件重复运行也没有任何提示。

write-tree

  为当前的index(注意:此时暂存区可能有多个文件)创建一个tree对象。把update-index和write-tree分开的目的,我认为是Git为了获得更细粒度的控制能力。

read-tree

  将一个的tree对象(可以以--prefix指定其对应的目录名,这个目录此时还不存在)读入index。通过这个命令以及update-index、write-tree,我们就可以任意地装配出任何目录-文件的结构了。注意我这里使用的是“装配”而非“组装”,是因为这三个命令是无法进行目录结构的拆分的。

commit-tree

  指定一个tree对象,以此创建一个commit对象。如果对一个commit对象再次运行该命令,可以git log看到完整的提交历史,也即这两个commit对象。

update-ref

   安全地更新一个用对象ID表示的文件的引用。其结果和git branch指定某个分支(对应于update-ref的引用)为某个commit(对应于update-ref的对象ID)一样。

  轻量级tag对象是可以通过update-ref进行创建的。

symbolic-ref

   给一个标记(如最常见的HEAD)指定一个引用。不指定引用则读取这个标记当前的引用。

gc

   清理文件。实际上是将文件进行打包压缩。

verify-pack

  查看通过gc进行的已打包的git对象。

 

 

 

 阅读的时候遇到了两处翻译错误,我已提交了pull request:

1.第9-2节“-stdin 指定从标准输入设备 (stdin) 来读取内容,若不指定这个参数则需指定一个要存储的文件的路径。”应为“要读取的文件的路径”。

2.第9-4节 “然后可以用git cat-file命令...”,下面用的是du命令。实际原文中在这里没有提到“git cat-file”。


作者:五岳
出处:http://www.cnblogs.com/wuyuegb2312
对于标题未标注为“转载”的文章均为原创,其版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

 
posted @ 2015-11-01 15:51  五岳  阅读(2838)  评论(0编辑  收藏  举报
回到顶部