GIT是如今最流行的版本控制系統。今年系統總結過一次關於GIT的使用，抽時間整理成文，分爲幾個章節進行簡述一下。
基礎概念
我們知道GIT是一種版本控制系統，那就首先了解一下什麼是 “版本控制”，比較官方的解釋是，版本控制系統是一種記錄一個或若干個內容變化，以便將來查詢特定版本修訂情況的系統。簡言之就是，你的修改只要提到到版本控制系統，基本都可以找回，版本控制系統就像一臺時光機器，可以讓你回到任何一個時間點。
瞭解了版本控制系統的功能，我們知道就算你把代碼改的一塌糊塗，照樣可以恢復到我們過去的任何一個時間點，工作量卻微乎其微。是不是很amazing。
大概瞭解了版本控制系統之後，總結一下版本控制系統有哪些優點：
1. 記錄文件所有歷史變化。這是版本控制系統的基本能力；
2. 隨時恢復到任意時間點。得益於版本控制系統的歷史記錄功能。此刻，我們便可以感受時光機器般的體驗，不怕改錯代碼做錯事了；
3. 支持多功能並行開發。通常版本控制系統都支持分支功能，這就保證了並行開發的可行性，通過不同的分支實現不同的功能；
4. 多人協作並行開發。公司的項目開發多是需要多人協作開發的，有了支持多人協作開發的版本管理，將會事半功倍；
除了上面介紹的幾個比較常見的優點，版本控制系統的好處還有很多，就不一一列舉了，可以通過實踐自己逐漸體悟總結。下面也會基於GIT做更多介紹。
常見類別
版本控制系統常見類別有三種：本地版本控制系統、集中式版本控制系統、分佈式版本控制系統；
本地版本控制系統，代表有RCS(Revision Control System)，Linux下面的可用來作爲配置文件管理的版本控制工具，本人簡單嘗試了一下，工作使用不多；
關於其優缺點，簡述如下：
優點：
1. 簡單，很多系統中都有內置；
2. 適合管理文本，如系統配置；
缺點：
1. 管理少量文件，不支持項目的管理；
2. 支持的文件類型單一；
3. 不支持遠程，網絡傳輸；
集中式版本控制系統，代表如CVS，SVN(Subversion)，SVN是曾經最流行的版本管理系統，很多人都有用過，因而對於集中式版本控制系統很多人都很瞭解它。
關於其優缺點：
優點：
1. 適合多人團隊協作開發；
2. 代碼集中化管理；
缺點：
1. 單點故障；
2. 必須聯網，無法單機工作；
優點就不多說了，大家可能對缺點更是記憶深刻。單點故障，集中式管理的缺點，代碼集中在一臺機器上，這個問題其實可以通過備份集羣解決；必須聯網工作，這個缺點我是深入痛覺，一旦公司網絡出現問題，幾個小時甚至一天無法工作的經歷都有。由於這些缺點，便有了分佈版本控制系統。
分佈式版本控制系統，代表就是今天要說的GIT了。想知道GIT有多流行嗎？看看GITHUB就知道了，現在很多公司都已經把自己的代碼庫遷移到了GIT。本人由於各種原因，近兩年已經到了第三家公司，其中每家都聽過一次GIT的分享。可見GIT在如今的流行程度，也說明了分佈式版本控制系統是如今的趨勢。
關於分佈式版本控制系統，這裏只說優點：
1. 適合多人團隊協作開發；
2. 代碼集中化管理；
3. 可以離線工作；
4. 每個計算機都是一個完整倉庫；
1、2兩點SVN也可以做到，說一下3、4點。分佈式版本管理系統每個計算機都有一個完整的倉庫，修改可以本地提交，這樣就可以做到離線工作。沒有了SVN令人抓狂的斷網無法工作的問題。每個計算機都是一個完整的倉庫，也就沒有了SVN的單點故障。
GIT與SVN的比較
GIT的作者Linus一直比較痛恨集中方式版本控制系統。雖然有很多已知免費的集中式版本控制系統，但是在2002之前提交Linux源碼的方式都是通過diff提交給Linus的，然後進行手工合併。下面讓我們來以GIT與SVN作爲代表，來看看爲什麼Linus痛恨集中式版本管理系統，而喜歡分佈式版本管理系統。下面具體比較一下它們的區別：
1. GIT是分佈式的，SVN爲集中式的。這是常識，兩者最重要的區別，也是後面所有區別的基石；
2. GIT隨處都是版本庫，SVN只有一箇中央版本庫。因爲GIT是分佈式的所以能做到到處都是版本庫，而SVN是集中式的，所以只有一箇中央倉庫。因而GIT能夠做到無需網絡提交，到處到時版本庫，壓根不用擔心提交速度問題，不用時刻依賴與網絡工作，不用擔心單點故障。當工作完成之後直接推送遠程即可實現工作協作；
3. GIT沒有全局版本號，SVN有全局版本號。因爲GIT版本庫到處都是，之間沒有實時共享數據，所以無法確保版本號的唯一性，無法使用全局版本號，分佈在各個機器上的版本庫版本號使用40位的HASH值取代。重複的情況是存在的，從數學的角度考慮，可能性是2的63次方分之一，基本可忽略。而對於SVN，唯一版本，所以能夠做到使用全局的版本號，版本號採用自增的方式；
4. GIT把內容按元數據存儲，SVN按文件存儲。GIT存儲的不是實際的文件，而是指向性數據。SVN保存的是文件數據。當GIT切換版本的時候，實際上切換的是元數據，而且本地操作，快捷有效；
5. GIT記錄文件快照，SVN記錄文件差異。GIT的元數據，即指向性數據指向的是實際的文件快照，這也是GIT能夠快速切換版本的一個原因。SVN保存的文件數據是各個版本之間的文件差異，所以切換版本的時候需要逐級的差異計算，速度比較慢，而且還需網絡傳輸。當工程較大時，速度與GIT相比差異會相當的大。
6. GIT的內容完整性高，SVN完整性低。因爲GIT的數據記錄都有HASH值校驗，所以內容完整性較高。而SVN則沒有此功能，內容完整性低。；
以上就是本人總結的關於GIT與SVN的一些差異。
GIT架構
GIT的架構，可以分爲幾個部分：本地工作區(working directory)、暫存區(stage area, 又稱爲索引區, index)、本地倉庫(local repository)、遠程倉庫副本與遠程倉庫(remote repository)。如下圖(自己畫的，比較醜)：
上圖展示了git的整體架構，以及和各個部分相關的主要命令。具體命令的使用在後期的文章做更詳細的介紹。先看了解說明下其中涉及的各個部分。
工作區(working directory)：工作區，簡言之就是你工作的區域。對於git而言，就是的本地工作目錄。工作區的內容會包含提交到暫存區和版本庫(當前提交點)的內容，同時也包含自己的修改內容。
暫存區(stage area, 又稱爲索引區index)：暫存區是git中一個非常重要的概念。是我們把修改提交版本庫前的一個過渡階段。查看GIT自帶幫助手冊的時候，通常以index來表示暫存區。在工作目錄下有一個.git的目錄，裏面有個index文件，存儲着關於暫存區的內容。git add命令將工作區內容添加到暫存區。
本地倉庫(local repository)：就是版本控制系統的倉庫，不過是存在於本地電腦中。當執行git commit命令後，會將暫存區內容真正提交到倉庫之中。在工作區下面有.git的目錄，這個目錄下的內容不屬於工作區，裏面便是倉庫的數據信息，上面提到的暫存區相關內容也在其中。
遠程版本庫(remote repository)：遠程版本庫與本地倉庫概念基本一致，不同之處在於一個存在遠程，可用於遠程協作，一個卻是存在於本地。通過push/pull可實現本地與遠程的交互；
遠程倉庫副本：可以理解爲存在於本地的遠程倉庫緩存。如需更新，可通過git fetch/pull命令獲取遠程倉庫內容。使用fech獲取時，並未合併到本地倉庫，此時可使用git merge實現遠程倉庫副本與本地倉庫的合併。
.git文件一覽
看看.git這個目錄的下文件結構，如下圖：
簡要說明一下各個文件中所存放的內容信息：
HEAD，當前所在位置，其實就是工作區的在版本庫中的那個提交點，最終會指向一個40位的HASH值；
config，當前版本庫的專有配置文件，如使用命令git config user.name poloxue便會記錄在此文件；
description：被gitweb (Github的原型)用來顯示對repo的描述。
hooks：git有一套可以自動運行在 git 任一有意義階段的腳本文件hooks, 如commit/release/pull/push等狀態之前或者之後，個人思考的一個用處，如pre-push可以用來強制進行代碼檢查。
index：存放暫存區(stage area)的相關信息；
info/exclue：可以做到和.gitignore相同的事情，用於排除不要包含進版本庫的文件。區別就是，此文件不會被共享。
refs/heads：目錄下有關於本地倉庫的所有分支；
refs/remote：目錄下有關於遠程倉庫的所有分支；
object：目錄下存放的就是實際的數據文件，關於其中的存放方式暫時還不瞭解，有興趣可以研究一下；
本節從版本控制引出分佈式版本控制，比較分佈式版本控制系統與其他版本控制系統的區別。從而引入GIT，通過與SVN的比較可以明顯看出GIT的優秀之處。然後對GIT的架構進行整體簡單介紹，內容比較理論。期望在理清自己思路的同時，不會導致別人的思路混亂。
好了，就說這麼多！文中如有錯誤，請幫忙指正！謝謝！
更多內容，待續 ...
附錄：
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
https://git-scm.com/book/zh/v2
http://blog.csdn.net/csfreebird/article/details/7925281
http://blog.csdn.net/zhaizu/article/details/47027183?ref=myread
http://www.cnblogs.com/lzlsky/p/5306323.html