在具體瞭解Git之前，首先需要我們瞭解一下VCS，即版本控制系統（version control system）
1、什麼是版本控制系統
版本控制是一種記錄一個或若干個檔案內容變化，以便將來查閱特定版本修訂情況的系統。版本控制系統不僅可以應用於軟體原始碼的文字檔案，而且可以對任何型別的檔案進行版本控制。
有了它你就可以將某個檔案回溯到之前的狀態，甚至將整個專案都回退到過去某個時間點的狀態，你可以比較不同版本檔案的變化細節，查出最後是誰修改了哪個地方。也就是無論檔案最後被修改成什麼樣子，你都可以輕鬆恢復到原先的樣子，但是額外增加的工作量卻微乎其微。
2、我們為什麼要用版本控制
世界上無數大大小小的開發專案，都在使用各種各樣的版本控制系統，原因在於它的優點對於一個專案開發來說是無比重要。
比如一個最簡單的開發團隊，也許就兩三個人，他們共同完成一個軟體的開發。每個人都在修改、新增、刪除著自己本地硬碟上的程式碼，當他們需要把這些程式碼彙總起來時，麻煩出現了。到底誰改了哪些檔案？具體是檔案裡的哪部分被改動過？A人員修改的內容會不會把B人員的修改的內容覆蓋掉，彙總工作就變得很危險，需要非常小心，一旦出錯後果不堪設想。顯然此時效率將會是無比的低下，如果某個地方出錯，可能整個彙總工作就要重來一遍。這只是兩三人的小團隊，如果是幾十人幾百人的大團隊呢？那將會是噩夢。
如果這個團隊採用了版本控制，那麼版本控制軟體在每次提交檔案的時候，都會主動合併所有人的修改，並解決可能發生的衝突。每個人手裡一直都是彙總好的程式碼，當開發進行到一定階段，可以直接拿去測試，不需要再有額外的工作來浪費時間。
3、版本管理系統的演變
（1）本地版本控制系統
許多人習慣用複製整個專案目錄的方式來儲存不同的版本，或許還會改名加上備份時間以示區別。 這麼做唯一的好處就是簡單，但是特別容易犯錯。 有時候會混淆所在的工作目錄，一不小心會寫錯檔案或者覆蓋意想外的檔案。
為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的資料庫來記錄檔案的歷次更新差異。
這種形式主要實現了基本的程式碼版本管理，但缺點是無法讓多人同時對一個版本庫進行修改。這個也和當時軟體規模不夠大有關，也沒有這樣的需求。
（2）集中化版本控制系統
接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？ 於是，集中化的版本控制系統（Centralized Version Control Systems，簡稱 CVCS）應運而生。 這類系統，諸如 CVS、Subversion等，都有一個單一的集中管理的伺服器，儲存所有檔案的修訂版本，而協同工作的人們都通過客戶端連到這臺伺服器，取出最新的檔案或者提交更新。 多年以來，這已成為版本控制系統的標準做法。
這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。 現在，每個人都可以在一定程度上看到專案中的其他人正在做些什麼。 而管理員也可以輕鬆掌控每個開發者的許可權，並且管理一個 CVCS 要遠比在各個客戶端上維護本地資料庫來得輕鬆容易。
事分兩面，有好有壞，集中管理的伺服器最顯而易見的缺點是中央伺服器的單點故障問題。 如果當機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。 如果中心資料庫所在的磁碟發生損壞，又沒有做恰當備份，毫無疑問你將丟失所有資料，包括專案的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。 本地版本控制系統也存在類似問題，只要整個專案的歷史記錄被儲存在單一位置，就有丟失所有歷史更新記錄的風險。
集中式版本控制系統另外一個大的問題就是必須聯網才能工作，如果不能連線到中央伺服器上，就不能對檔案進行提交，還原，對比等操作。
（3）分散式版本控制系統
於是分散式版本控制系統（Distributed Version Control System，簡稱 DVCS）面世了。 在這類系統中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客戶端並不只提取最新版本的檔案快照，而是把程式碼倉庫完整地映象下來。 這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個映象，把本地倉庫恢復。 因為每一次的克隆操作，實際上都是一次對程式碼倉庫的完整備份。
許多這類系統都可以指定和若干不同的遠端程式碼倉庫進行互動。因此你就可以在同一個專案中，分別和不同工作小組的人相互協作。 你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。
參考：