GIT版本管理

1.关于版本控制

版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统

 

采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的

状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查

出是谁最后修改了什么地方从而造成某些怪异问题，又是谁在何时报告了某个功能缺陷，

等等。使用版本控制系统通常还意味着，就算你胡来搞砸了整个项目，把文件改的改，删的

删，你也可以轻松恢复到原先的样子。而由此额外增加的工作量却微乎其微。

 

本地版本控制系统

 

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以

示区别。这么做唯一的好处就是简单，不过坏处却不少：有时候会混淆所在的工作目录，弄

错了文件丢了数据就没了后退的路。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种

简单的数据库来记录文件的历次更新差异

 

其中最流行的一种叫做rcs，工作原理基本上就

是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录着对应文件

修订前后的内容变化。所以，根据每次修订后的补丁，rcs 可以通过不断打补丁，计算出各

个版本的文件内容。

 

集中化的版本控制系统

如何让在不同系统上的开发者协同工作？于是，集中化的

版本控制系统（ Centralized Version Control Systems，简称CVCS ）应运而生。SVN（Subversion）、CVS，Subversion 以及Perforce 等，都有一个单一的集中管理的服务器，保存

所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或

者提交更新。多年以来，这已成为版本控制系统的标准做法

 

这么做最显而易见的缺点是中央服务器的单点故障。若是宕机一小

时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果中央服务器的磁盘发

生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风险。最坏的情况是

彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的

话依然是个问题，你不能保证所有的数据都已经有人提取出来。本地版本控制系统也存在类

似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新信息的风险。

 

 

分布式版本控制系统

分布式版本控制系统（ Distributed Version Control System，简称DVCS ）诸如Git，Mercurial，Bazaar 还有Darcs 等，客户端并不只提取最

新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作

用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取

操作，实际上都是一次对代码仓库的完整备份

 

许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可

以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流

程，比方说层次模型式的工作流，这在以前的集中式系统中是无法实现的。