一、关于版本控制
版本控制是一种记录若干文件内容变化,以便将来查阅特定版本修订情况的系统。我们通常仅对保存着软件源代码的文本文件做版本控制,但实际上,你可以对任何类型的文件进行版本控制。
采用版本控制系统(VCS),你就可以将某个文件回溯到之前的状态,甚至将整个项目回退到某个时间点状态;你可以比较文件变化的细节,查查最后是谁修改了哪个地方,从而导致出怪异的问题, 又是谁何时报告了谋个功能缺陷等。
二、备份文件
本地版本控制器之前,许多人喜欢用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示却别。
好处:简单。
坏处:有时候会混淆所在的工作目录,一旦弄错文件丢了数据就无法撤销恢复。
三、本地版本控制器
本地版本控制器由来是,为了解决备份文件的存在的问题,人们就开发了许多种本地版本控制系统,它大都采用某种简单的数据库来记录文件的历次更新差异。
典型代表是一种叫做rcs,它的工作原理基本上就是保存并管理文件补丁(patch)。文件补丁是一种特定格式的文件,记录着对应文件修订前后的内容变化。所以,根据每次修订后的补丁,rcs可以通过不断打补丁,计算出各个版本的文件内容。
四、集中化的版本控制系统
接下来遇到一个新问题,如何在不同系统上的开发者协同工作?于是,集中化的版本控制系统(Centrailized Version Control Systems,简称CVCS)应运而生。
这类系统的代表,如CVS,Subversion以及Perforce等。都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连接到这台服务器,取出最新的文件或者提交更新。
好处:
相对于较老式的本地VCS来说,每个人都可以在一定程度上看到项目中其他人正在在做些什么;
管理员也可以轻松掌控每个开发者的权限,并管理一个CVCS要远比在各个客户端维护本地数据库来的轻松容易。
坏处:
中央服务器的单点故障,如果宕机一小时,则在这一小时内,谁都无法提交更新,也无法协同工作。
中央服务器磁盘发生故障,碰巧备份不够及时,还是会丢失数据的风险。最坏的情况是侧地丢失整个项目的所有历史更改记录,而被客户端提取出来的某些快照数据除外。
五、分布式版本控制系统
于是分布式版本控制系统(Distributed Version Control System,简称DVCS)面世了。
在这类系统中典型的,像Git、Mercurial、以及Darcs等,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。
好处:
这么一来,任何一处协同工作用的服务器发生故障,事后可以用任何一个镜像出来的本地仓库恢复。
更进一步,这类系统都可以指定和若干不同的远端代码仓库进行交互,你就可以在同一个项目,分别和不同的小组的人相互协作。
六、Git简史
Linux内核开源项目有着众广的参与者,绝大多数的Linux内存维护工作都花在提交补丁和保存归档的繁杂事务上(1991-2002年间)。
到2002年,整个项目组开始启用分布式版本控制系统BitKeeper来管理和维护代码。
到了2005年,开发BitKeeper的商业公司同Linux内核开源社区合作关系结束,他们收回了免费BitKepper的权利。迫使Linux开源社区(特别是Linux的缔造者Linus Torvalds)不得不吸取教训,只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。
自从2005年以来,Git日臻成熟完善,在高度易用的同时,仍然保留着初期的设计的目标。极其适合管理大项目,有着令人难以置信的非线性分支管理系统,可以应付复制的项目开发需求。
七、Git基础
1.直接记录快照,而非差异比较
大多数其他系统:则只关心文件内容具体差异。这类系统(CVS、Subversion、Perforce、Bazaar等)每次记录有哪些文件做了更新,以及都更新了哪些行的什么内容。
Git:只关心文件数据的整体是否发生变化,并不保存这些前后的差异数据。实际上,Git更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引。为了提高性能,若文件没有变化,Git不会再次保存,而只是对上次保存的快照作一链接。
2.近乎所有操作都是本地执行
CVCS:用CVCS的话,差不多所有操作都需要连接网络。
Git:绝大多数操作都只需要访问本地文件和资源,不同连网。因为它在本地磁盘上就保存着所有当前项目的历史更新,所以处理起来速度飞快。
场景:
如果要浏览项目的历史,Git不同跑到外面的服务器上去取回数据,而直接从本地数据库读取后展示给你看。
如果想看一个当前版本和一个月前的版本之间有何差异,Git会取出一个月前的快照和当前文件作一次差异运算,而不同请求远程服务器来做这件事情。
如果CVCS的话,没有网络或者断开VPN你就无法做任何事情。使用Git话,就算你在飞机或者火车上,都可以非常愉快地频繁提交更新,等到有了网络的时候在上传到远程仓库。
3.时刻保持数据完整性
保存数据方式:在保存到Git之前,所有数据都要进行内容的校验和计算,并将此结果作为数据的唯一标示和索引。换句话说,不可能在你修改了文件或目录之后,Git一无所知。如果文件在传输时变得不完整,或者磁盘损坏导致文件缺失,Git都能察觉。
算法原理:Git使用SHA-1算法计算数据校验和,通过对文件的内容或目录的结构计算出一个SHA-a哈希值,作为指纹字符串。该字符串由40个十六进制字符(0-9及a-f)组成,看起来是:24b9da6552252987aa493b52f8696cd6d3b00373。
实际应用:Git的工作完全依赖于这类指纹字符串,所有保存在Git数据库中的东西都是由此哈希值来做索引的,而不是靠文件名。
4.多数操作仅添加数据
因为任何一种不可逆操作,比如删除数据,都会使回退或重现历史版本变得困难重重。
在别的VCS中,若还未提交更新,就有可能丢失或者混淆一些修改的内容。
但在Git里,一旦提交快照之后,就安全不用担心丢失数据,特别养成定期推送到其它仓库习惯的话。
八、文件的三种状态
对于任何一个文件,在Git内都只有三种状态:
已提交(committed):表示该文件已经被安全地保存在本地数据库中。
已修改(modified):表示修改了某个文件,但还没有提交保存。
已暂存(staged):标识把已修改的文件放在下次提交时要保存的清单中。
九、文件流转的三个工作区域
Git管理项目时,文件流转的三个工作区域:Git的工作目录、暂存区域、以及本地仓库。
Git目录:每项目都有一个Git目录,它是Git用来保存元数据和对象数据库的地方,该目录非常重要,每次克隆镜像仓库的时候,实际拷贝的就是这个目录里面的数据。
工作目录:从项目中取出某个版本的所有文件和目录,用以开始后续的工作的目录。这些文件实际上都是从Git目录中的压缩对象数据库汇总提取出来的,接下来就可以在工作目录中对这次文件进行编辑。
暂存区域:只不过是个简单文件,一般都放在Git目录中。有时候人们会把这个文件叫做索引文件,不过标准的说话是叫暂存区域。
我们可以从文件所处的位置判断状态:
如果是Git目录中保存着的特定版本文件,就属于已提交状态;
如果作了修改并放入暂存区域,就属于已暂存状态;
如果自上次取出后,做了修改单还没有放到暂存区域,就是已修改状态;
十、Git工作流程
1.在工作目录中修改某些文件。
2.对修改后的文件进行快照,然后保存到暂存区域。
3.提交更新,将保存在暂存区域的文件快照永久转存到Git目录中。
十二、初次运行Git前的配置
Git提供了一个叫做git config的工具(实际是git -config命令,只不过可以通过git加一个名字来呼叫此命令),专门用来配置或读取相应的工作环境。而正是这些环境变量,决定了Git在各个环节具体工作方式和行为。
这些变量可以存放在一下三个不同的地方:
1./etc/gitconfi文件:系统中对所有用户都普遍适用的配置,若使用git config --system读写的就是这个文件。
2.~/.gitconfig文件:用户目录下的配置文件只适用于该用户,若使用git config --global读写的就是这个文件。
3.当前项目的git目录的配置文件(也就是工作目录中的.git/config文件):这里的配置仅仅对当前项目有效,每一个级别的配置都会覆盖上层相同的配置,所以.git/config文件里的配置会覆盖/etc/gitconfig中的同名变量。
在Windows系统上,Git会找寻用户主目录下的.gitconfig文件,主目录即$Home变量指定的牡蛎,一般是C:\Documents and Settings\$USER。此外,Git还会尝试寻找/etc/gitconfig文件,只不多看当初Git装在什么位置,此目录作为根目录来定位。
1.用户信息
第一个要配置的是你的个人用户名称和电子邮件。这两条配置非常重要,每次Git提交时都会引用者两条信息,说明是谁提交了更新,所以会随更新内容一起被永久纳入历史记录:
git config -global user.name "Peng CX"
git config -global user.email xiang18610224709@live.com
使用--global选项,那么更改的配置文件就位于你用户主目录下的那个,以后你所有的项目都会默认使用这里配置的用户信息。如果在某个特定的项目中使用其他名字或邮件,只要去掉--golable宣子昂重新配置即可,新的设定保存到当前项目的.git/config文件里。
2.文本编辑器
接下来要设置的是默认使用的文本编辑器。Git需要输入一些额外的消息的时候,会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器,一般可能是Vi或Vim。如果你有其它偏好,比如Emacs的话,可以重新设置:
git config --global core.editor emacs
3.差异分析工具
还有一个比较常用的是,在解决合并冲突使用哪种差异分析工具,比如要改用vimdiff的话:
git config --global merge.tool vimdiff
Git可以理解kdiff3,tkdiff,meld,xxdiff,emerge,vimdiff,gvimdiff,ecmerge,和opendiff等合并工具的输出信息。当然你也可以指定自己的开发工具。
4.查看配置信息
查看检查已有的配置信息,可以使用:
git config --list
有时会看到重复的变量名,那就说明它们来自不同的配置文件(比如/etc/gitconfig和~/.gitconfig),不过最终Git实际采用最后一个。
可以直接查阅谋个环境变量的设定,只要把特定的名字跟在后面即可,如下:
git config user.name
5.获取帮助
想了解Git的格式工具该怎么用,可以阅读它们的使用帮助,方法有:
git help
git --help