软件开发之版本控制方式

编程知识 更新时间:2023-05-02 22:15:51

一、版本控制方式

1.1、集中式版本控制

        所有的版本数据是集中存放在中央服务器的,用户的本地设备就只有自己以前所同步的版本。如果不连网的话,用户就看不到历史版本,也无法切换版本验证问题,或在不同分支工作。

        实际工作中用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。

                                    

                                                   图1.1 集中式版本控制

        集中式版本控制系统最大的毛病就是必须联网才能工作,而且,所有数据都保存在单一的服务器上,一旦服务器出现问题所有数据都会丢失,当然可以定期进行备份。这种方式如果在局域网内还好,带宽够大、速度够快。可如果在互联网上,遇到网速慢的话,可能提交一个10M的文件就需要5分钟,等待时间太长了。


1.2、分布式版本控制

       分布式版本控制系统没有“中央服务器”,clone的时候并不是复制指定版本的快照,而是把所有的版本信息仓库全部同步到本地,这样就可以在本地查看所有版本历史,可以离线在本地提交,只需在连网时push到相应的服务器或其他用户那里。由于每个用户那里保存的都是所有的版本数据,所以,只要有一个用户的设备没有问题就可以恢复所有的数据。当然,这增加了本地存储空间的占用。

       在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

图1.2 分布式版本控制


1.3、经典的版本控制工具
1.3.1集中式版本控制工具

       CVS:最早的、开源、免费。由于自身设计的问题,会造成提交文件不完整、版本库莫名其妙损坏的情况。

       SVN:开源、免费。修正了CVS的一些稳定性问题,是目前用得最多的集中式版本库控制系统。

       ClearCase:收费、安装比Windows还大、运行比蜗牛还慢。IBM 收购了原本制作的Rational公司。

       VSS:集成在Visual Studio中。反人类的设计。

注:

       集中式版本控制系统最大的问题就是必须联网才能工作,受网络状况、带宽影响。

1.3.2分布式式版本控制工具

       Git:速度很快,这对于诸如Linux kernel这样的大项目来说自然很重要,Git最为出色的是它的合并跟踪(merge tracing)能力。

       BitKeeper:促使Git的诞生,在Git诞生11年之后开始全部免费。

1.4、集中式VS分布式版本控制

特点与比较:

        集中式:

                   通过与中心服务器的连接执行所有操作,必须联网。

       分布式:

                   1、快速,本地客户机操作,不联网也不影响工作,离线工作,DVCS 比 Subversion 快大约3-10倍

                   2、可以实现非常灵活的工作流(传统的集中式工作流 + 特殊工作流 + 特殊工作流和集中式工作流的组合)。

                   3、安全性更高,因为每个人电脑里都是完整的版本库,坏了复制一份即可,CVCS中央服务器出问题就GG。

                   4、两台电脑互相访问不了或某一台电脑未开机不能执行复制(交换修改)时,通常有一台电脑充当中央服务器。

                   5、分支管理功能强大。

比较项

集中式(SVN)

分布式(Git)

是否有中央服务器

有。开发人员需要从中央服务器获得最新版本的项目然后在本地开发,开发完推送给中央服务器。因此脱离服务器开发者是几乎无法工作的。

没有中央服务器,开发人员本地都有 Local Repository。

网络依赖

必须要联网才能工作,而且对网络的依赖性较强,如果推送的文件比较大而且网络状况欠佳,则提交文件的速度会受到很大的限制。

分布式在没有网络的情况下也可以执行commit、查看版本提交记录、以及分支操作,在有网络的情况下执行 push 到 Remote Repository。

文件存储格式

按照原始文件存储,体积较大。

按照元数据方式存储,体积很小。

是否有版本号

没有

分支操作的影响

创建新的分支则所有的人都会拥有和你一样的分支。

分支操作不会影响其他开发人员。

提交

提交的文件会直接记录到中央版本库。

提交是本地操作,需要执行push操作才会到主要版本库。

二、分布式工作流程

       同传统的集中式版本控制系统(CVCS)不同,Git的分布式特性使得开发者间的协作变得更加灵活多样。 在集中式系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像。 而在 Git中,每个开发者同时扮演着节点和集线器的角色——也就是说,每个开发者既可以将自己的代码贡献到其他的仓库中,同时也能维护自己的公开仓库,让其他人可以在其基础上工作并贡献代码。 由此,Git的分布式协作可以为项目和团队衍生出种种不同的工作流程,接下来会介绍几种利用了Git的这种灵活性的常见应用方式。 我们将讨论每种方式的优点以及可能的缺点;你可以选择使用其中的某一种,或者将它们的特性混合搭配使用。

2.1、集中式工作流

       集中式系统中通常使用的是单点协作模型——集中式工作流。 一个中心集线器,或者说仓库,可以接受代码,所有人将自己的工作与之同步。 若干个开发者则作为节点——也就是中心仓库的消费者——并且与其进行同步。                 

图2.1 集中式工作流

       这意味着如果两个开发者从中心仓库克隆代码下来,同时作了一些修改,那么只有第一个开发者可以顺利地把数据推送回共享服务器。 第二个开发者在推送修改之前,必须先将第一个人的工作合并进来,这样才不会覆盖第一个人的修改。 这和Subversion(或任何CVCS)中的概念一样,而且这个模式也可以很好地运用到Git中。

        如果在公司或者团队中,你已经习惯了使用这种集中式工作流程,完全可以继续采用这种简单的模式。 只需要搭建好一个中心仓库,并给开发团队中的每个人推送数据的权限,就可以开展工作了。Git不会让用户覆盖彼此的修改。例如 John和 Jessica同时开始工作。John完成了他的修改并推送到服务器。 接着Jessica尝试提交她自己的修改,却遭到服务器拒绝。 她被告知她的修改正通过非快进式(non-fast-forward)的方式推送,只有将数据抓取下来并且合并后方能推送。 这种模式的工作流程的使用非常广泛,因为大多数人对其很熟悉也很习惯。

       当然这并不局限于小团队。 利用Git的分支模型,通过同时在多个分支上工作的方式,即使是上百人的开发团队也可以很好地在单个项目上协作。

2.2、集成管理者工作流

        Git允许多个远程仓库存在,使得这样一种工作流成为可能:每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。这种情形下通常会有个代表“官方”项目的权威的仓库。 要为这个项目做贡献,你需要从该项目克隆出一个自己的公开仓库,然后将自己的修改推送上去。 接着你可以请求官方仓库的维护者拉取更新合并到主项目。 维护者可以将你的仓库作为远程仓库添加进来,在本地测试你的变更,将其合并入他们的分支并推送回官方仓库。整个流程看起来是这样的:

       1、项目维护者推送到主仓库。

       2、贡献者克隆此仓库,做出修改。

       3、贡献者将数据推送到自己的公开仓库。

       4、贡献者给维护者发送邮件,请求拉取自己的更新。

       5、维护者在自己本地的仓库中,将贡献者的仓库加为远程仓库并合并修改。

       6、维护者将合并后的修改推送到主仓库。

                                                       图2.2 集成管理者工作流

2.3、司令官与副官工作流

        这其实是多仓库工作流程的变种。一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式,例如著名的Linux内核项目。被称为副官(lieutenant)的各个集成管理者分别负责集成项目中的特定部分。所有这些副官头上还有一位称为司令官(dictator)的总集成管理者负责统筹。司令官维护的仓库作为参考仓库,为所有协作者提供他们需要拉取的项目代码。整个流程看起来是这样的:

       1、普通开发者在自己的特性分支上工作,并根据 master 分支进行变基。 这里是司令官的 master 分支。

       2、副官将普通开发者的特性分支合并到自己的 master 分支中。

       3、司令官将所有副官的 master 分支并入自己的 master 分支中。

       4、司令官将集成后的 master 分支推送到参考仓库中,以便所有其他开发者以此为基础进行变基。                

图2.3 司令官与副官工作链路

       这种工作流程并不常用,只有当项目极为庞杂,或者需要多级别管理时,才会体现出优势。 利用这种方式,项目总负责人(即司令官)可以把大量分散的集成工作委托给不同的小组负责人分别处理,然后在不同时刻将大块的代码子集统筹起来,用于之后的整合。

更多推荐

软件开发之版本控制方式

本文发布于:2023-04-29 01:25:00,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/199f27646ec593c83f3f0dde1a8680cc.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:版本   方式   软件

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!

  • 109748文章数
  • 27905阅读数
  • 0评论数