1.關於版本控制Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

既然你有需要使用 Git ，那相信你對備份這個詞肯定不會陌生，我們對於一些文件或者工程專案一定會做備份（畢竟 ctrl+z 不會總能幫到你），備份的方式因人而異，很多人習慣用備份的日期或者 version1、2 這樣的字尾以示區別，這種方式很簡單，這個可以算是最基礎的手動實現的版本控制。

可是，這樣做的缺點也很多。

如果現在的這個版本不好用，想找回以前那版，可是誰還記得哪份檔案對應哪個版本啊。。。

這麼多檔案，想刪不敢刪，如果哪天要用怎麼辦。。。

最要命的是，如果一個檔案是很多個人共同寫成的，當你拿到別人寫好的檔案試圖合併時，哪些是共同的部分，哪些是他修改過的。。。

於是版本控制系統出現了。

2.集中式與分散式版本控制系統 先說集中式版本控制系統，諸如 CVS、SVN 等，都有一個單一的集中管理的伺服器，儲存所有檔案的修訂版本，而協同工作的人們都通過客戶端連到這臺伺服器，取出最新的檔案或者提交更新。多年以來，這已成為版本控制系統的標準做法。

這種做法帶來了許多好處，最重要的是讓協同工作以及管理變得十分方便。但是，這種做法最顯而易見的缺點就是中央伺服器的存在。 首先，必須聯網才能工作，如果在區域網內還好，頻寬夠大，速度夠快，可如果在網際網路上，遇到網速慢的話，工作效率會變得極低。 另外，中央伺服器的單點故障是更加嚴重的問題，如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。如果中心資料庫所在的磁碟發生損壞，又沒有做恰當備份，毫無疑問將丟失所有資料——包括專案的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。本地版本控制系統也存在類似問題，只要整個專案的歷史記錄被儲存在單一位置，就有丟失所有歷史更新記錄的風險。

於是，分散式版本控制系統面世了。

分散式版本控制系統中沒有“中央伺服器”的概念，每個人的電腦上都是一個完整的版本庫。這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個映象出來的本地倉庫恢復。因為每一次的克隆操作，實際上都是一次對程式碼倉庫的完整備份。另外，在分散式版本控制系統中就不需要聯網了，因為版本庫就在你自己的電腦上。

這類系統都可以指定和若干不同的遠端程式碼倉庫進行互動。籍此，你就可以在同一個專案中，分別和不同工作小組的人相互協作。

3. Git 的誕生 雖然Linux系統是由Linus建立，但事實上有著為數眾多的參與者。絕大多數的 Linux 核心維護工作都花在了提交補丁和儲存歸檔的繁瑣事務上。到2002年，整個專案組開始啟用一個專有的分散式版本控制系統 BitKeeper 來管理和維護程式碼。 到了2005年，開發 BitKeeper 的商業公司同 Linux 核心開源社群的合作關係結束，他們收回了 Linux 核心社群免費使用 BitKeeper 的權力（這中間發生了很多事，對，很多事）。這就迫使 Linux 開源社群基於使用 BitKeeper 時的經驗教訓，開發出自己的版本系統，當然就是我們所要說的Git。 他們對新的系統制訂了若干目標：

- 速度 - 簡單的設計 - 對非線性開發模式的強力支援（允許成千上萬個並行開發的分支） - 完全分散式 - 有能力高效管理類似 Linux 核心一樣的超大規模專案（速度和資料量）

2005年以來，Git 日臻成熟完善，在高度易用的同時，仍然保留著初期設定的目標。它的速度飛快，極其適合管理大專案，有著令人難以置信的非線性分支管理系統。到了2008年，GitHub網站上線了，它為開源專案免費提供Git儲存，無數開源專案開始遷移至GitHub，包括jQuery，PHP，Ruby等等。