1.1 关于版本控制
什么是版本控制?我为什么要关心它呢?版本控制是记录一个或者若干文件的变化,以便于将来查看各种特定版本修订情况的系统.在本书中所展现的例子中,我们仅对保存着软件源代码的文本文件做版本控制管理
集中式版本控制系统
集中化的版本控制系统(Centralized Version Control System)简称CVCS,这类系统,诸如CVS,SubVersion以及 PerForce等,都有一个单一的集中管理的服务器,保存着所有文件的修订版本,而协同工作的人们通过客户端连接到这台服务器,取出最新的文件或者提交更新.多年以来这已经成为版本控制系统的标准做法.
这种做法带来了许多好处,特别是相对于老式的VCS来说.现在,每个人可以在一定程度上看到项目中的其他人正在做什么.而管理员也可以轻松的掌控每个开发者的权限,并且管理一个CVCS要远比在各个客户端上维护本地数据来的容易
事分两面,有好有坏.这么做最显而易见的缺点是中央服务器的单点故障.如果宕机一小时,那么在这一小时内,谁都无法提交更新,也无法协同工作,,要是中央服务器的磁盘发生故障,,碰巧没做备份,,或者备份不够及时,就会有丢失数据的风险.最坏的情况是丢失整个项目的所有历史更改记录.而被客户端偶然提取出来的某些快照就撑了恢复数据的希望.但这样的话依然是个问题,你不能保证所有的数据都有人事先完整提取出来过,本地的版本控制也存在类似的问题,只要整个项目历史记录被保存在单一的位置,就有丢失历史更新记录的风险.
分布式版本控制系统
于是分布式版本控制系统(Distributed Version Control System,简称DVCS)就出现了,在这类系统中,像Git,Mercurial,Bazaar以及Darcs等,客户端并不只是提取最新版本的文件快照,而是吧代码仓库完整的复制下来,这么一来,任何一处协同工做的服务器发生故障,事后都可以任何一个镜像下来的本地仓库恢复,因为每一次提取操作,实际上都是一次对代码仓库的完成备份.
更进一步,许多这类系统都可以指定若干不同的远端代码仓库进行交互,借此,你就可以在一个项目中,分别和不同小组的人相互协作.你也可以根据需要设定不同的协作流程,比如层次模式的工作流.而这是在以前的集中式版本控制系统中无法实现的.
1.2 Git
Git是怎样的一个系统呢
直接记录快照,而非差异比较
Git和其他版本控制系统的主要区别在于,Git只关心文件数据的整体是否发生变化,而大多数系统则只关心文件内容的具体差异.这类系统(CVS,SubVersion,Perforce,Bazaar等)每次记录有哪些文件做了更新,以及都更新了什么内容.Git并不保存这些前后变化的具体差异.实际上,Git更像是把变化的文件作为快照后,记录在一个微型的文件系统中.每次提交更新时,它会总览一遍所有文件的指纹信息并对文件做一快照,然后保存指向这一快照的索引,为提高性能,若文件没有变化,Git不会再次保存,而只对上一次保存的快照做一次链接
近乎所有的操作都是本地执行
因为本地保存着所有版本的历史更新
例如,如果要浏览项目历史更新摘要,Git不用跑到外面的服务器上去取回数据来,而直接从本地数据库中提取出来展示给你看
时刻保存数据的完整性
在保存到GIt之前,所有的数据都要进行内容的校验和计算,并将此结果作为数据的唯一标识和索引,换句话说,不可能在你修改了文件或者目录后,Git一无所知,这项特性作为Git设计哲学,建在整体架构的最底层.所以,如果文件在传输时变得不完整,或者磁盘损坏导致文件数据缺失,Git都能立即察觉.
多数操作权限添加数据
常用的Git操作大多仅仅是吧数据添加到数据库,因为任何一种不可逆的操作,比如删除数据,都会使回退或重现历史版本变得尤其困难,在Git中,一旦提交快照之后就完全不用担心数据丢失,特别是养成定期推送到其他仓库的习惯的话.
这种高可靠性令我们的开发工作安心不少,尽管去做各种实验性的尝试好了,再怎样也不会弄丢数据,
文件的三种状态
任何一个文件,在Git中都有三种状态:已提交(committed),已修改(modified),和已暂存(staged).已提交表示该文件已被安全的保存在本地数据库中了;已修改表示已经修改了某个文件,但是还没有提交保存;已暂存表示已经把下次要提交的文件保存在清单中.
每个项目都有一个Git目录(译注:如果git clone出来的话,就是其中的.git目录;如果git clone -bare的话,新建的目录本身就是git目录),它是git用来保存元数据和数据对象的地方.该目录非常重要,每次克隆镜像仓库的时候,这些文件其实都是从git目录中压缩对象数据库中提取出来的,接下来就可以在工作目录中对这些文件进行编辑
