关于软件配置管理中版本控制

闵啸 张名明 凌旺

（中国船舶重工集团公司第七二三研究所 江苏省扬州市 225011）

在实际的软件开发过程中，会产生大量的代码与文档，同时，相应需求具有不确定性，因此软件开发人员需要经常进行项目文件的迭代与修改，因此会进一步生成更多的文档，促使文档管理工作量增加。基于此，展开软件配置管理工作极为必要，特别是进行版本控制，能够帮助软件开发人员更好的记录与控制变更，值得重点探讨。

1 版本控制及其重要性的概述

1.1 版本控制的内涵

版本控制是一种软体工程技巧，借以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。实践中，主要依托透过文档控制记录程序各个模组的改动，并为每次改动编上序号[1]。现阶段，形成了一些简单的版本控制形式，例如，赋给图的初版一个版本等级“A”。当做了第一次改变后，版本等级改为“B”，以此类推等等。

1.2 软件配置管理中版本控制的重要性

从软件开发的形式来看，普遍使用团队合作的方式进行，实践中，会将同一软件的不同版本部署于不同的站点，为软件开发人员同时对软件进行更新处理提供支持。为了更为精准的确定软件漏洞位置，更好的实现软件漏洞修补，检索与运行不同版本的软件极为必要，能够迅速确定出是哪个版本的软件出现问题。

同时，目前的软件开发大多为迭代式，这意味着包含大量版本不同的程序副本。在以往的管理中，一般会简单的将所有副本进行保存，并标注相应的版本号。该方法虽然能够更好区分不同版本，但是也存在明显缺陷，具体有：

（1）效率低下。在上述版本管理方法中，要求软件开发人员标清所有版本并进行存储。由于软件的迭代数较大，因此经过较长时间的积累极容易发生错误。

（2）重复性工作较多。代码库需要不断的向软件开发人员授予读写权限，促使权限管理的工作量大幅上升。为了避免上述问题的发生，引入有效的版本控制极为必要。

另外，在软件开发的过程中，需要团队成员之间的良好配合，组织多个成员对同一文档或代码进行编辑。而对于团队内的不同成员来说，其在工作时间、工作强项等方面具有差异性，因此引入版本控制、可以进行文档与代码跟踪记录的平台是必然选择。

2 软件配置管理中版本控制的常见形式分析

2.1 集中式版本控制

在集中式版本控制模式中，不同系统开发者的协同工作成为现实。该模式主要使用了一个单一集中的服务器，对所有项目文件的修订版本进行保管。实践中，不同系统的开发者利用“check out”功能完成最新文件的提取，并在实现修改后递交至服务器。一般来说，版本控制允许多个开发人员在相同的时间段内针对同一文件展开修改更新，多数版本控制系统中均具有自动“merge”功能，完成对不发生冲突的更新进行融合。

诚然，集中式版本控制具有较高的应用优势，但是也存在着一定缺陷。其中，最为明显的缺陷在于极为依赖服务器。一旦服务器发生故障，任何客户端均无法展开更新的递交。同时，若是中心数据库在未进行备份的情况下发生损坏，则会导致所有数据均丢失，仅能够保留多个客户端的不同版本。这样的问题阻碍着软件项目开发的顺利展开。

2.2 分布式版本控制

对于分布式版本控制而言，其能够消除集中式版本控制的缺陷，降低了对服务器的依赖程度。实践中，客户端不仅仅进行基于最新版本的文件快照的提取，还会对中央代码仓库展开完整镜像。在这样的条件下，所有客户端均具备了相对完整的代码仓库备份。此时，即便中央服务器发生损耗，其中的数据均可以在任意一个客户端中得到全面恢复。

3 软件配置管理中版本控制的主要流程分析

3.1 总体流程说明

对于版本控制来说，其属于软件配置管理中的核心功能。版本命名系统促使所有在配置库中的元素命名具有唯一性成为现实。由于处于基线控制的软件配置版本证明了一定的阶段性工作，因此所有版本管理均在基线的管控下。一般来说，对于非基线控制的版本，相关软件开发人员可以在不经过审批的前提下展开随意变更修改。若是要修改锁定版本，版本控制的基本流程主要如下：

（1）创设配置项目。根据《配置管理计划》中的相关内容与要求，在配置数据库中进行属于任务范围内的配置项目创建[2]。

（2）修改未锁定的配置。在“check in”或“check out”功能的支持下，针对未锁定的配置展开更新修改。

（3）批准或审批。针对“计划”类的配置项目，要求相关管理人员进行审批；针对“技术文档”类的项目，需要展开技术审批。

（4）配置项的锁定。完成管理审批与技术审批后，将配置项目的状态由原有的未锁定状态变更至锁定状态。

（5）配置项目的变更。针对处于“锁定”状态的配置项目，要在变更控制标准流程的指导下完成实际的变更操作。

现阶段，版本控制一般由CASE 工具提供支持，实现对不同系统功版本存储的管理，并对系统组件的访问行为展开有效控制。实践中，必须要在系统中对组件进行提取，然后再进行编辑操作。当将其重新放入系统时，新的系统版本生成，并由版本管理系统赋予其以新的名称。在软件配置管理的版本控制中，最主要的内容包括检入检出控制、分支与合并以及历史记录。

3.2 检入检出控制

建立基线后，配置项目在配置数据库中得以良好保存，且此时的配置项目不能进行随意修改。但是，在软件开发的过程中，这些配置项目需要被修改，且在完成修改后依然要保存在同样的配置数据库内。在此过程中，落实检入检出控制极为必要。对于“检入”而言，促使软件配置项目由软件开发人员的工作空间转移至配置数据库中；对于“检出”而言，促使软件配置项目由配置数据库转移至软件开发人员的工作空间中。检入检出控制为软件开发人员访问对象的权限保证提供了支持，并在检出的同时对这一对象实现锁定。此时，当前检出版本在没有被转换前不能再更新这个变更的配置对象。

3.3 分支与合并

版本分支主要对主版本进行拷贝，并展开标记；版本合成主要对版本内容拷贝至另一个版本上从而形成新的版本，或是将两个版本的内容展开合并，最终形成新版本。

3.4 历史记录

对于版本控制的历史记录来说，其对软件的整个开发过程进行了跟踪与记录，方便软件开发人员对开发过程中不同阶段生成的新结果进行对比与分析，并将已修改的软件配置项目恢复至未修改状态[3]。同时，历史记录还综合了不同人员对配置项目所作出的修改，推动软件配置管理水平提升。

4 软件配置管理中版本控制系统的应用

4.1 版本控制系统的概述

本文选取Git 系统为例进行说明，该系统属于分布式版本控制系统，由于其免费且开源，以此在当前得到广泛应用。实践中，Git 系统普遍被应用于文件变更的跟踪。

4.2 版本控制系统的工作区域

4.2.1 Git 仓库

该工作区域主要用于保存项目数据以及数据库，是本软件版本控制系统中最核心的部分。在系统中，包含着“git clone”指令，能够对多台计算机中的仓库进行克隆。实践中，拷贝的内容均来源于Git 仓库。

4.2.2 工作目录

该工作区域包含着得从项目某个版本中提取出来的内容，主要来源于Git 仓库的压缩数据库，并保存于本地磁盘内。软件开发人员在修改时，可以在计算机本地磁盘内获取项目数据信息。

4.2.3 暂存区域

该工作区域主要实现了下次将要提交的文件列表信息的保存，普遍被设置于git directory 中。

4.3 版本控制系统的文件状态

在Git 系统中，存在于工作目录中的文件可以划分为两种状态，即跟踪状态与未跟踪状态。其中，对于处于跟踪状态的文件来说，可以进一步细分为未修改状态、修改状态以及暂存状态。此时，版本控制能够对跟踪文件进行管控，当软件开发人员对某一文件内容进行了修改，那么该文件就转变为修改状态。在这样的情况下，若想对该文件内容展开再一次修改，就需要使用“git add”指令，将待修改文件转入转存区域，并在“git commit”指令的支持下，将本次更改操作递交至Git 仓库内。随后，依托“git push”指令，促使其在远程服务器中完成记录。

4.4 系统的分支与合并

Git 系统具备强大的分支功能，软件开发人员可以利用该功能实现不同版本 的同时性开发，且能够随时切换至不同的版本中展开工作。在此基础上，可以将新增的分支特性融合至主分支中，促使在不变更现阶段稳定版本的前提下增加新功能。实践中，当软件开发人员提交一个对象后，Git 分支会自动向前移动，并指向最后一个提交对象。在Git 系统中，包含着HEAD 特殊指针，一般指向当前所在的本地分支。在“git check out”指令的支持下，该指针可以随时切换至的目前的工作分支。依托Git 系统的分支特性，可以将稳定的版本放在master 主分支上。在实际的软件开发过程中，若是出现漏洞需要修复或有不确定的新功能需要测试，可在当前的版本基础上新建一个分支。创建新分支的过程如下：利用“git check out”指令，加入分支名，即可在当前所在提交对象上完成新分支的创建。基于此，能够在不破坏主分支的基础上完成软件的漏洞修复以及新功能的安全测试。

5 总结

综上所述，在当前的软件开发中会将同一软件的不同版本部署于不同的站点，方面不同人员同时对软件进行更新处理，因此展开软件配置管理，特别是版本控制极为必要。在版本控制工作的支持下，软件开发人员的冗余工作得到明显减少，且可以实现版本历史记录的跟踪与记录，推动着软件开发工作的顺利展开。对于Git 软件来说，其免费且开源，能够为版本控制工作的更好展开提供平台支持，更好的发挥出人在软件开发项目管理中的作用。