基于Git的分布式版本控制系統的設計與實現

劉悅之

同濟大學，上海 201804

0 引言

現在的軟件項目開發中，必然涉及版本控制。

版本控制的功能在于跟蹤記錄整個軟件的開發過程，包括軟件本身和相關文檔。在空間上可以保證完成集中統一管理，解決一致性和冗余問題。在時間上全程跟蹤記錄工具將會自動記錄開發過程中的每個更改細節，和不同時期的不同版本，以便對不同階段的軟件及相關文檔進行表示并進行差別分析，對軟件代碼進行可撤消的修改，便于匯總不同開發人員所做的修改，輔助協調和管理軟件開發團隊。

1 為什么選擇Git

1.1 Git的優勢

相對于其他流行的軟件版本開源管理軟件，Git的優勢在哪里呢？

1.1.1 對網絡的依賴性更低

雖然現在網絡非常普及，但是并不是隨時隨地都有高速網絡，低速的網絡會讓人心情煩躁，有時候就呆呆地盯著屏幕上的提交進度，什么事情也干不了。而Git的絕大部分操作在本地完成，不用和集中的代碼管理服務器交互，只有最終完成的版本才需要向一個中心的集中的代碼管理服務器提交。

1.1.2 方便的原子提交跟蹤

Git的每次提交都會根據SHA-1算法生成唯一的commit id。而不像CVS那樣都是對單個文件分別進行版本的更改。所以當你跟蹤以前某次提交的代碼時，不用考慮到底提交了哪些文件，所有的變動代碼會一次性的取出來。

1.1.3 更方便的分支合并操作

Git的分支管理相對CVS 等系統容易多了，無論是建立新的分支，還是在分支之間切換都一條命令完成，不需要建立多余的目錄。分支之間合并時，不僅代碼會合并在一起，提交歷史也會保留，這點非常有助于分支的管理與追蹤。

1.2 Git的缺點

對于一個大型項目而言，在項目管理的過程中，只依靠Git原有的功能來進行版本控制管理是遠遠不夠的。Git無法滿足大型項目的管理要求。

1.2.1 對創建倉庫、分支等操作的管理權限分級

Git是分布式版本控制工具，任何人都可以將自己的本地創建的分支、標簽等注入到中央代碼倉庫中，極大的提高了中央倉庫的維護成本。不利于大型項目的協同開發。

1.2.2 對多個倉庫進行同步管理。

Git的每個倉庫都是獨立的，無法做到跟蹤軟件本身的同時，對軟件相關文檔也進行跟蹤，無法對不同階段的軟件及相關文檔進行差別分析，不利于團隊協作和管理。

1.2.3 保護中央代碼倉庫以防污染

在用戶從本地倉庫向中央倉庫提交代碼的過程中，Git只是做了純文本的合并，對代碼規范、質量等不會做檢查，無法避免中央代碼倉庫受到污染。

1.2.4 并行開發代碼的提交沖突

并行開發帶來的又一大問題就是代碼提交沖突，Git需要手動解決沖突后再次提交，極大的降低了工作效率。

所以我們需要設計一個基于Git的分布式版本控制系統來彌補Git所存在的不足。

2 系統設計的主要思路

為了彌補Git的不足，本系統提出了一下方法來滿足大型項目版本控制的需求。

2.1 多倉庫同步分支管理

眾所周知，對于一個大型項目，由于需求的不確定性風險、決策層溝通障礙風險或者技術路線風險都會使得項目發布日期的不斷延遲并最終導致整個項目的失敗，為了避免這種情況，大型項目往往采用了迭代式的開發模型，當開發到某一階段就會發布一個版本給用戶，然后根據用戶體驗，修改存在的問題或增加新的功能。

在大型項目的版本管理控制過程中，不僅需要管理項目源代碼倉庫，源代碼對應的測試腳本倉庫、環境配置文件倉庫、與之相關的任何文件倉庫都應該能被同時追蹤，以此來保證項目生命周期內的任意時刻被追蹤時，其相關的其他倉庫代碼也能被迅速定位。

為此，本系統提供了分支管理模塊來讓開發人員更好的管理各個發布版本并同步各代碼倉庫。

系統用主分支來維護團隊內部日常代碼開發的主線。每當要發布新版本時，系統管理員就可以選擇各個倉庫主分支上的某一次的原子提交，在這些原子提交上打上同一個標簽，并在所有倉庫中新建分支。這樣，我們就可以根據標簽同時追蹤所有的倉庫代碼。

對于新建的分支，它已經包含主分支上直到所選擇的原子提交的所有代碼，當團隊成員向本次準備發布的新版本提交特定的代碼時，選擇此版本的分支，新代碼將只會提交到新分支上，而不會影響主分支上的代碼。

如果提交的代碼不僅僅需要用應用在此新版本上，在其他以后的版本或者已存在的版本也需要使用，比如修復了項目的某些BUG，那么開發人員可以使用代碼合并模塊來合并此次提交到特定的一些分支上。

2.2 多重代碼審核減少污染

由于Git只是一個分布式的版本控制軟件，它并不對代碼質量進行審核，如何更有效的減少中央倉庫污染對大型項目至關重要。對于一個大型項目，開發團隊人數往往由幾十人甚至幾百人組成，每個人每天都要向中央代碼庫提交多次代碼，在開發人員將代碼提交到中央代碼倉庫之前，檢查代碼是否符合規范、是否有潛在的質量問題、避免互相影響造成額外的、非預期的錯誤是本系統的又一大主要功能。

首先，代碼審核模塊為管理員提供了配置項目子系統的功能。管理員可以將項目代碼中不同目錄下的文件劃分不同的項目子系統，也可以稱作模塊。并設置一個或多個子系統審核員，他們可以是項目模塊負責人、模塊設計者等等。當開發人員提交了新代碼后，系統將解析新代碼對源代碼中哪些文件做了修改，并根據文件路徑辨識此次變動屬于哪些子系統，然后，通知子系統審核員去審核新代碼。如果審核人員發現代碼存在問題，審核人員可以在系統中寫下批注，拒絕提交成功，并退回給開發人員以供修改。

如果提交的代碼通過了審核人員的審核，系統將把新代碼文件上傳至中央編譯服務器，在中央編譯服務器中，首先克隆一份最新的中央代碼倉庫的副本，將變動文件注入到副本中，如果在新代碼提交的過程中，有別的開發者對同樣的文件做了修改，并先一步提交到了中央代碼倉庫，那么此新代碼將會和中央代碼倉庫中的文件產生沖突，系統將把沖突信息返回給開發人員，要求他基于最新的代碼倉庫提交變動代碼。

當新代碼通過了以上兩步檢驗后，中央編譯服務器將對新代碼進行編譯，以保證新的改動不會導致原程序編譯失敗。

2.3 減少代碼提交沖突

本系統提供了一種名叫依賴補丁的選項，來盡量避免代碼沖突產生，提高工作效。

當開發人員A提交了代碼補丁文件后，系統會根據A的補丁文件記錄的所有修改文件的歷史記錄，通知其相關的開發人員，并把A的補丁文件上傳至服務器，此時B發現克隆到本地的最新中央代碼倉庫中不包含A的代碼，他可以通過本系統下載A的補丁文件，并將補丁文件加載到本地倉庫中，在此基礎上進行開發。這樣就可以大量避免代碼沖突的產生。

但是，由于B的代碼是基于A的補丁，如果B的代碼被先審核，那么在補丁加載的過程中一定會失敗，因為此時中央代碼倉庫中并不存在A的代碼。所以B提交代碼的時候必須選擇A的補丁作為依賴項，在A的補丁沒有通過審核流程時，B的補丁則不能被審核。以此來保證正確的審核順序。

2.4 實時代碼合并

隨著項目的開發周期越來越長，分支和提交也會越來越多，也就不可避免的出現代碼合并與分支合并。

根據本系統設計的理念，每個發布版本所對應的分支都是相對獨立的，這樣盲目的的分支合并存在的風險遠遠大于某次特定代碼的合并。所以，我們通過實時的代碼合并，來取代風險較大的分支合并。

根據系統設計，主分支是項目開發的主線，其他分支上的大部分的代碼提交，除了那些與發布版本特性有關的代碼，都應該被合并到主分支上。為此，系統在開發人員提交代碼時，系統會默認當前提交需要被合并到主分支，同時會提醒開發人員，如果他的當前提交不需要合并到主分支，則應該取消該選項。新代碼通過了子系統管理者的審核后，會在主分支和原目標分支上分別作沖突檢查和編譯檢查。

正如我們前面提到過的，代碼倉庫中不僅有項目的核心代碼，也會有測試腳本、配置文件等其他文件。由于編譯檢查是串行工作的，如果讓腳本代碼、配置文件這些變動更頻繁的提交，每次合并都要對整個項目進行編譯檢查的話，會大大影響核心代碼的提交效率，從而影響工作效率。所以本系統還提供了讓管理員手動合并代碼的功能。對于已經提交的代碼，系統管理員可以將多次提交一次性地合并到多個分支上，這些合并只會做代碼沖突檢查，而不會做編譯檢查。

3 結論

版本控制是大型軟件項目管理必不可少的一部分，版本控制系統的合理設計和使用，是提高開發效率，減少人為錯誤的一大保證。本文通過分析Git的優缺點，給出了構建合理可靠的版本控制系統的實現方案，并已應用到一個具體的大型項目中。

[1][美]Jon Loeliger.Version Control with Git[M].東南大學出版，2010.

[2][美]Travis Swicegood.Pragmatic Version Control Using Git[M].電子工業出版社，2010.

[3][中]蔣鑫，Git權威指南[M]，機械工業出版社，2011.