版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统,方便查看更改历史,备份以及恢复以前的版本,保证多人的协作不出问题
1. 原始的版本控制
版本控制工具的黑暗时代:
-
最原始的版本控制是纯手工的版本控制:修改文件,保存文件副本
-
保存副本命名随意→版本难辨新旧,不能辨别每一版的修改内容
2. 版本控制的起源:diff与patch
-
在最初的版本控制软件出现之前,其实已经有了比较好用的源码比较与打补丁的工具:diff与patch
-
Linus Torvalds(Linux之父)也对这两个工具偏爱有佳
-
在1991-2002年之间,即使CVS出现之后,Linus一直使用diff和patch管理着Linux的代码
-
diff与patch是用于源码版本控制中的两个最基本的概念
2.1 diff简介:diff用来比较两个文件或者目录之间的差异
2.2 Patch简介:Patch是diff的反向操作
我们把上述差异结果保存到文件中,例如diff.txt中,那么这个diff.txt就可以用来从left.c推算出right.c的内容,或者从right.c推算出left.c的内容
3. RCS:最早期的本地版本控制工具
RCS(Revision Control System)
-
RCS作为非常古老的版本工具,远远在SVN和已经退役的CVS之前,它的古老程度应该比Web开发的ASP前代的CGI还要久远
-
如果想对版本管理实现方式进行深入研究的话,研究RCS是一种最为简单的入手方式
-
RCS采用把diff的集合,采用RCS自己的格式保存到磁盘中(可以通过diff -n left.c right.c 产生RCS格式的diff内容),能通过这些diff集合,重新回到文件修改的任何历史中的点
4.CVS & SVN:集中式版本控制工具
5.Git:Linus的第二个伟大作品
5.1Git的起源
Linux之父Linus是坚定的CVS反对者,他也同样的反对SVN。2002年Linus顶着开源社区精英的口诛笔伐,选择了一个商业版本控制系统BitKeeper作为Linux内核的代码管理工具。和CVS/SVN不同,BitKeeper是属于分布式版本控制系统。
Git诞生大事记:
-
2005年4月3日,开始开发Git
-
2005年4月6日,项目发布
-
2005年4月7日,Git就可以作为自身的版本控制工具
-
2005年4月18日,发生第一个多分支合并
-
2005年4月29日,Git的性能就已经达到了Linus的预期
-
2005年6月16日,Linux核心2.6.12发布,那时Git已经在维护Linux核心的源代码
5.2集中式 VS 分布式
(1)记录差异还是记录快照
-
Git和其他版本控制系统(包括Subversion和近似工具)的主要差别在于Git对待数据的方法
-
感念上来区分,其他大部分系统以文件变更列表的方式存储信息
-
这类系统(CVS,Subversion,Perforce,Bazaar等等)将保存的信息看作是一组基本文件和每个文件随时间逐步积累的差异
-
Git不按照以上方式对待或保存数据,反之,Git更像是把数据看作是对小型文件系统的一组快照
-
每次提交更新,或在Git中保存项目状态时,它主要对当时的全部文件制作一个快照并保存这个快照的索引
-
为了高效,如果文件没有修改,Git不再重新存储该文件,而是只保留一个链接指向之前存储的文件,Git对待数据更像是一个快照流
(2)脆弱的中央库 VS 强壮的分布库
5.3选择合适的版本控制工具
SVN不适合的领域:
跨地域的协同开发
对代码的高质量追求和代码门禁
Git不适合的领域:
不适合Word等二进制文档的版本控制
因为:Git无锁定/解锁模式,故不能排他式修改,整体的读授权,不能将读授权精细到目录级别
解决方案:版本库按目录拆分
6.结语:Git是什么
Git是一个版本控制工具,而且是一个开源的分布式版本控制工具
按照Linus本人的描述,Git的很多命令设计是源于BitKeeper,但是Git有更多属性
-
极快的速度
-
简单的设计
-
对非线性开发模式的强力支持(允许成千上万个并行开发的分支)
-
完全分布式
-
有能力高效管理类似Linux内核一样的超大规模项目(速度和数据量)
本章小结
-
版本控制工具的发展历史经过:原始人工维护状态,本地RCS,集中式如CVS,SVN和分布式如Git
-
版本控制工具提供了协作开发的能力,借助它们我们可以回到任何时间的代码状态
-
集中式版本控制工具,几乎所有的动作都需要服务器的参与,并且数据安全性与服务器关系很大
-
Git是分布式版本控制工具,除了服务器之前进行按需同步之外,所有的提交操作都不需要服务器