Git——版本控制概論（一）

隨着信息技術的發展，軟件開發已不是小手工做坊，軟件的規模和複雜度已經再也不適合一我的單打獨鬥的開發了，

團隊協做變得至關重要，若是沒有VCS（版本控制系統Version Control System），團隊開發就會變得亂七八糟。

 

1.版本控制概論

版本控制是記錄咱們對文件、目錄或工程等修改的歷史，方便查看更改歷史，備份以便恢復之前的版本，多人協做。

 

最先的版本控制是純手工的版本控制：修改文件，保存文件副本。

因爲許多時候偷懶省事，保存副本文件名比較隨意，時間一長就不知道哪一個是哪一個了。

 

因爲手工管理比較麻煩且混亂，後來就出現了本地版本控制，記錄文件每次的更新，能夠對每一個版本作一個快照，或是記錄補丁文件。

 

可是本地版本控制系統偏向於我的使用，或者多個使用的人必須使用相同的設備，若是須要多人協做那就很差辦了。

因而乎，集中版本控制（Centralized Version Control Systems，簡稱CVCS）應運而生。

在CVCS中，全部版本數據都保存在服務器上，一塊兒工做的人從服務器上同步更新或上傳本身的修改。

可是，全部版本數據都保存在服務器上，用戶要獲取最新版本就須要從中心服務器上下載，若是網絡的帶寬高還好，不然會很是麻煩。

同時查看歷史版本也必須聯網，若是不聯網就看不到歷史版本，沒法切換版本驗證問題，或不能在不一樣分支工做。

並且，全部數據都保存在一臺服務器上，數據面臨丟失的風險。

 

針對CVSC的以上缺點，就出現了分佈式的版本控制（Distributed Verson Control System，簡稱DVCS），經常使用的有Git、Mercurial等。

DVCS不是複製指定版本的快照，而是把全部的版本信息倉庫所有同步到本地，這樣就能夠在本地查看全部的歷史版本，

能夠離線在本地提交，只須要在聯網時推送到相應的服務器或其它用戶那裏。

因爲每一個用戶那裏保存的都是全部的版本數據，因此只要一個用戶的設備沒有問題就能夠恢復全部數據。

固然，這增長了本地存儲空間的佔用。

 

2.集中式VS分佈式

因爲在實際生產中基本上都是使用集中式或分佈式的版本控制，因此下面會分析一下各自的優缺點。

（1）集中式版本控制系統

集中式的版本控制系統的版本庫是集中存放在中央服務器，而幹活的時候，用的都是本身的電腦，

因此先要從中央服務器取得最新的版本，而後開始幹活，幹完活後，再把本身的或推送個中央服務器。

中央服務器就比如一個圖書館，你要改一本書，必須先從圖書館借出來，而後回到家中改，改完以後再放回圖書館。

集中式版本控制最大的毛病就是必須聯網才能工做，沒有網你什麼都作不了，並且受制於帶寬。

 

（2）分佈式版本控制

與集中式版本控制相比，分佈式版本控制沒有「中央服務器」，每一個成員的電腦都是一個完整的版本庫，

這樣你工做的時候就不須要聯網，由於版本庫就在你本身的電腦上。那麼多人是如何協做的了？

若是你修改了一個文件A，你的同時也修改了一個文件A，那麼你倆之間就能夠相互推送，而後決定最終的版本。

還集中式版本系統相比，分佈式版本系統的安全性要高的多，由於每一個人都有一個完整的庫，因此某我的的電腦出了問題不打緊，

只要從別人那裏複製一份就好了，而集中式的版本控制系統要是「中央服務器」出了問題，那就完全玩完。

在實際使用分佈式版本控制系統的時候，大部分時候對於兩我的來講可能不在一個局域網以內，

這樣兩臺電腦就不能直接訪問，或者說雙方並非同時在線，以及其餘種種緣由，所以在分佈式系統中須要有一臺服務器充當「中央服務器」，

可是隻是方便不一樣庫之間的版本推送，沒有它也能工做。

固然，咱們接下來要詳細介紹的Git並非說只有沒必要聯網這麼簡單。

CVS做爲最先的開源並且免費的集中式版本控制系統，直到如今依然還有很多人在使用。

因爲CVS自身設計的問題，會形成提交文件不完整，版本庫莫名其妙損壞的狀況。

一樣是開源並且免費的SVN修正了CVS的一些穩定性問題，是目前使用最多的集中式版本控制系統。

Git是一種很是流行的分佈式版本控制系統，也能夠叫作源代碼管理系統，相對於SVN來講就是分佈式。

SVN須要一箇中心服務器保存源代碼，全部的開發者都是用客戶端進而這個服務器交互。

GIt的強大之處並不是在於分佈式，而是其對源代碼存儲的機制（使用快照），

因爲這樣的機制的存在，你能夠大量頻繁的使用分支來工做，經過分支來隔離功能開發的過程。