關于軟件配置管理中版本控制

閔嘯 張名明 凌旺

（中國船舶重工集團公司第七二三研究所 江蘇省揚州市 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 軟件來說，其免費且開源，能夠為版本控制工作的更好展開提供平臺支持，更好的發揮出人在軟件開發項目管理中的作用。