面向工资编程,面向面试学习!

关于版本控制

在软件开发中我们可能有过这样的经验:

  1. 有一天你希望将某个文件恢复到几天前的内容,于是又得花费时间和精力一点点的修改。
  2. 希望删除某个文件,又担心未来可能会用到这个文件,于是将这个文件重新命名下,依然保留在项目文件夹中,这样造成项目里面拥有了大量的冗余文件。
  3. 某一天因为自己的不小心将整个项目文件夹删除了,无法恢复项目,多少天的心血一朝付之东流,气的想死。
  4. 在多人共同开发项目时,多人对同一个文件内容作了修改,如果文件内容没有合并,那么最终的文件内容可能并不是正确的内容。

你可能想到了,如果我们有一个这样的系统问题就解决了:

  1. 它能够记录一个或者多个文件内容变化,以便把编辑过的文件复原到以前的状态,并能显示编辑前后的内容差异;
  2. 即使删除了某个文件,我们依然可以在将来的任何时间从系统中找到这个文件。
  3. 当不小心删除了本地项目文件夹后,可以轻松的从远程项目仓库中拉取最近一次的项目版本。
  4. 当编辑旧文件后,试图覆盖较新的文件的时候(即上传文件到服务器时),系统会发出警告,因此可以避免在无意中覆盖了他人的编辑内容。

这样的系统称之为版本控制系统。 在本教程所展示的例子中,我们对保存着软件源代码的文件作版本控制,但实际上我们可以对任何类型的文件进行版本控制。
版本控制系统的演变史:

本地版本控制系统

最开始的时候,人们希望在自己的本地电脑进行版本控制,于是很久以前人们就开发了很多本地版本控制系统,原理大多是采用某种简单的数据库来记录文件的历次更新差异。
代表软件:rcs(https://www.gnu.org/software/rcs/)
rcs的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。

本地版本控制

优点:可以在本地容易的进行版本控制
缺点:如果本地电脑发生故障,有丢失所有更新历史更新记录的风险。

集中化的版本控制系统

为了让在不同系统上的开发者协同工作,共同完成一个项目,人们开发了集中化的版本控制系统(Centralized Version Control Systems,简称 CVCS)。
代表软件:CVS(https://www.nongnu.org/cvs/)、Subversion(https://subversion.apache.org/) 、 Perforce(https://www.perforce.com/)
这类系统都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。 多年以来,这已成为版本控制系统的标准做法。

集中化的版本控制

优点:可以多人协同开发一个项目;管理员可以很容易的管理每个开发者的权限,管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
缺点:如果中央服务器发生故障,那么将无法提交更新,无法协同工作,有丢失数据的风险

分布式版本控制系统

为了解决集中化版本控制系统的缺点,人们开发了分布式版本控制系统(Distributed Version Control System,简称 DVCS)。
代表软件:Git(https://git-scm.com/)、Mercurial(https://www.mercurial-scm.org/)、Bazaar(https://bazaar.canonical.com/en/)、Darcs(http://darcs.net/)
在这类系统中,客户端既拉取最新版本的文件快照,又把代码更新历史仓库完整地镜像下来。 这样做的好处是,如果任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。

分布式版本控制

许多这类系统都可以指定和若干不同的远端代码仓库进行交互。这样你就可以在同一个项目中,分别和不同工作小组的人协作工作。 你可以根据需要设定不同的协作流程,比如层次模型式的工作流,这在以前的集中式系统中是无法实现的。