git 是一個版本控制系統。
官方的解釋是：版本控制(Revision control)是一種軟件工程技巧，籍以在開發的過程中，確保由不同人所編輯的同一檔 案都得到更新。
下面上網上別人寫的白話文解釋：
一群志同道合的人身處祖國各地，希望來合作開發一個項目，假設這個項目是使用 c 語言寫 的（當然用任何語言都可以的）。那麼大家怎麼合作呢？用信件？效率太低。用郵件，不好實現多人溝通。用 google group 吧，可開發階段中的源代碼沒法科學管理。用自建的網站吧，需要人力物力財力來支撐，這個時候版本控制系統就派上用場了。它可以讓一個團隊裡的不同的人在不同地點、不同時間開發和改進同一個項目， 並且在大部分的時間裡，版本控制系統會聰明的幫你把不同的人在不同地點不同時間修改的代碼融合到項目中去。（當然 在一些特殊的情況，還是需要人去決定到底哪些代碼需要加入到項目中，這個在後面討論不遲，先讓大家對版本控制有一 個好印象，呵呵）
現在有很多的版本控制工具：VSS、CVS、SVN，那為什麼還要用Git呢？其中一個最重要的原因就是git是分布式的，而其它都是集中式的。
許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單。不過壞處也不少：有時候會混淆所在的工作目錄，一旦弄錯文件丟了數據就沒法撤銷恢復。
為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是采用某種簡單的數據庫來記錄文件的歷次更新差異（見圖 1-1）。
圖 1-1. 本地版本控制系統
其中最流行的一種叫做 rcs，現今許多計算機系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後，也可以使用 rcs 命令。它的工作原理基本上就是保存並管理文件補丁（patch）。文件補丁是一種特定格式的文本文件，記錄著對應文件修訂前後的內容變化。所以，根據每次 修訂後的補丁，rcs 可以通過不斷打補丁，計算出各個版本的文件內容。
接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這台服務器，取出最新的文件或者提交更新。多年以來，這 已成為版本控制系統的標准做法（見圖 1-2）。
圖 1-2. 集中化的版本控制系統
這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。現在，每個人都可以在一定程度上看到項目中的其他人正在做些什麼。而管理員也可以輕松掌控每個開發者的權限，並且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕松容易。
事分兩面，有好有壞。這麼做最顯而易見的缺點是中央服務器的單點故障。如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。要 是中央服務器的磁盤發生故障，碰巧沒做備份，或者備份不夠及時，就還是會有丟失數據的風險。最壞的情況是徹底丟失整個項目的所有歷史更改記錄，而被客戶端 提取出來的某些快照數據除外，但這樣的話依然是個問題，你不能保證所有的數據都已經有人事先完整提取出來過。本地版本控制系統也存在類似問題，只要整個項 目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。
於是分布式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客戶端並不只提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工作用的服務器發生故障，事後都可以用任何一個鏡 像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份（見圖 1-3）。
圖 1-3. 分布式版本控制系統
更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的
