如何選擇版本控制系統——爲何選擇Git版本控制系統

版本控制系統

「代碼」做爲軟件研發的核心產物，在整個開發週期都在遞增，不斷合入新需求以及解決bug的新patch，這就須要有一款系統，可以存儲、追蹤文件的修改歷史，記錄多個版本的開發和維護。因而，版本控制系統（Version Control Systems）應運而生，主要分爲兩類，集中式和分佈式。

集中式版本控制系統

集中式版本控制系統的特色是隻有一臺中央服務器，存放着全部研發數據,而其它客戶端機器上保存的是中央服務器最新版本的文件快照，不包括項目文件的變動歷史。因此，每一個相關人員工做開始前，都須要從這臺中央服務器同步最新版本,才能開始工做。

集中式版本控制系統的優勢：

1.操做簡單，使用沒有難度，可輕鬆上手。

2.文件夾級權限控制，權限控制粒度小。

3.對客戶端配置要求不高，無需存儲全套代碼。

集中式版本控制系統的缺點：

1.網絡環境要求高，相關人員必須聯網才能工做。

2.中央服務器的單點故障影響全局，若是服務器宕機，全部人都沒法工做。

3.中央服務器在沒有備份的狀況下，磁盤一旦被損壞，將丟失全部數據。

分佈式版本控制系統

分佈式版本控制系統的特色是每一個客戶端都是代碼倉庫的完整鏡像，包括項目文件的變動歷史。全部數據分佈的存儲在每一個客戶端，不存在中央服務器。可能有人會問，咱們公司使用Git分佈式存儲工具，也有「中央服務器」啊？其實,這個所謂的「中央服務器」僅僅是用來方便管理多人協做，任何一臺客戶端均可以勝任它的工做，它和全部客戶端沒有本質區別。

分佈式版本控制系統的優勢：

1.版本庫本地化，版本庫的完整克隆，包括標籤、分支、版本記錄等。

2.支持離線提交，適合跨地域協同開發。

3.分支切換快速高效，建立和銷燬分支廉價。

分佈式版本控制系統的缺點：

1.學習成本高，不容易上手。

2.只能針對整個倉庫建立分支，沒法根據目錄創建層次性的分支。

SVN vs Git

SVN和Git做爲集中式和分佈式版本控制系統的表明，都有廣大的使用羣體，二者的優缺點常常被比較。其實，工具對咱們來講，就是幫助咱們有效提高工做的效率與質量，最適合的就是最好的。咱們引用幾個開發場景來看看兩個版本控制工具的適用範圍。

場景一：

公司A，非純技術開發，項目包含大量媒體設計文件，相關人員只需下載本身關注的部分文件；員工PC電腦配置不高，沒有空間拷貝整個項目資料。

適用：SVN

分析：只需公司有一個足夠大的服務器硬盤，員工本地只存儲本身相關的文件夾，沒必要下載不想關的媒體文件，避免浪費文件傳輸時間。

場景二：

公司B，嵌入式底層開發，項目人員較多而且分佈在兩個城市，代碼龐大；用分支管理多機種並行開發，機種間常常相互合併新特性，新patch。

適用：Git

分析：

1.Git有能力高效管理相似Linux內核同樣的超大規模項目；

2.Git實現了離線開發、代碼審覈特性，解決了跨地域協同開發中代碼質量和編碼協同的問題；

3.分支管理功能強大，便於查詢和追溯分支間的提交歷史；

4.Git基於DAG（有向非環圖）的設計比SVN的線性提交提供更好的合併追蹤，避免沒必要要的衝突，提升工做效率

場景三：

公司C，某行業軟件開發，包含敏感重要數據，代碼倉庫和版本發佈權限掌握在客戶手中，代碼安全要求高，公司開發人員先將代碼提交到本地倉庫，只有在客戶審覈經過才能提交到發佈倉庫。

適用：Git

分析：

1.Git經過哈希加密保證數據的完整性，防止惡意篡改；

2.代碼分佈存儲，異地容災，保證數據安全；

3.Git支持團隊成員自建本地版本庫和分支，只有客戶發出合併請求，開發人員才能提交代碼，客戶能夠對提交說明、代碼規範等方面逐一審覈。

總結

不難看出，Git憑藉自身的優點，完美解決了大多數公司對版本控制工具的訴求。在當今敏捷開發成爲主流,研發週期短，跨地域協同開發多的大形勢下，選擇Git是大勢所趨。也正由於如此，國內外有不少基於Git的雲端代碼託管服務，目前，做者就正在使用華爲軟件開發雲(www.hwclouds.com/devcloud/)配置管理服務託管代碼，後面我也會詳細介紹它的使用方法。