Git是目前世界上最先進的分佈式版本控制系統。
本地版本控制系統
分佈式的版本控制系統
發展歷程：
Linus在1991年創建了開源的Linux，從此，Linux系統不斷髮展，已經成爲最大的服務器系統軟件了。
Linus雖然創建了Linux，但Linux的壯大是靠全世界熱心的志願者參與的，這麼多人在世界各地爲Linux編寫代碼，那Linux的代碼就必須要有一個管理工具來管理。
事實是，在2002年以前，世界各地的志願者把源代碼文件通過diff的方式發給Linus，然後由Linus本人通過手工方式合併代碼！
到了2002年，Linux系統已經發展了十年了，代碼庫之大讓Linus很難繼續通過手工方式管理了，社區的弟兄們也對這種方式表達了強烈不滿，於是Linus選擇了一個商業的版本控制系統BitKeeper，BitKeeper的東家BitMover公司出於人道主義精神，授權Linux社區免費使用這個版本控制系統。
Linux社區牛人聚集，有一個夥計試圖破解BitKeeper的協議，結果被BitMover公司發現了，於是BitMover公司怒了，要收回Linux社區的免費使用權。這個時候Linus向BitMover公司道個歉，保證以後不再發生這樣的事情。
道歉歸道歉，但實際上linus花了兩週時間自己用C寫了一個分佈式版本控制系統，這就是Git！一個月之內，Linux系統的源碼已經由Git管理了！從些Git分佈式版本軟件就此誕生了，Git迅速成爲最流行的分佈式版本控制系統。
2008年，GitHub網站上線了，它爲開源項目免費提供Git存儲，無數開源項目開始遷移至GitHub，包括jQuery，PHP，Ruby等等，很多很多。
整個的事情就是這樣，如果不是當年BitMover公司威脅Linux社區要收回使用權，現在我們可能就沒有免費而超級好用的Git分佈式版本系統了。
最早Git是在Linux上開發的，很長一段時間內，Git也只能在Linux和Unix系統上跑。不過，慢慢地有人把它移植到了Windows上。現在，Git可以在Linux、Unix、Mac和Windows這幾大平臺上正常運行了
Git的原理
Git的使用流程是
工作區（Working Directory）------->版本庫（Repository）暫緩區------>倉庫
Git版本工具的部署與使用
工作區（Working Directory）
就是我們在本機的目錄，就是我們的工作區，比如/root/myproject
[root@git myproject]# pwd
/root/myproject
版本庫（Repository）
工作區有一個隱藏目錄.git，這個.git不算工作區，而是Git的版本庫。
Git的版本庫裏存了很多東西，其中最重要的就是稱爲stage（或者叫index）的暫存區，Git爲我們自動創建了一個分支master，以及指向master的一個指針叫HEAD。
我們把文件往Git版本庫裏添加的時候，要執行兩步：
第一步：git add 把文件添加進去，實際上就是把文件添加到暫存區；
第二步：git commit -m “版本描述信息” 提交到版本庫，實際上就是把暫存區的所有內容提交到倉庫的當前分支
創建Git版本庫時，Git自動爲我們創建了一個master分支，所以git commit就是往master分支上提交更改。
你可以簡單理解爲，需要提交的文件修改通通放到暫存區，然後，一次性提交暫存區的所有修改。
當工作區有文件更改，執行git add時，暫緩區就變成以下這樣了：
Git版本工具的部署與使用
git add 命令實際上就是把工作區要提交的內容放到暫存區（Stage），然後，執行git commit就可以一次性把暫存區的所有修改提交到分支
一但執行git commit提交後，那麼工作區就是“乾淨”的：
現在版本庫變成了這樣，暫存區就沒有任何內容了：
Git版本工具的部署與使用
svn的優勢：
優異的跨平臺支持，對windows平臺支持非常友好。
簡單易用，安裝後稍微培訓下就知道怎麼操作。
代碼，需求，文檔，涉及稿都可以用svn進行管理，適合不同部門的技術非技術的同事協作。
git的優勢：
去中心化：Git是沒有中心服務器的，每個人機器上都是一個完整的庫，我們平時開發代碼時的中央服務器其實和我們自己機器上的庫內容是完全一樣的（格式有點不同，是bare的）。雖然平時大家都是將代碼提交到中央服務器上再統一pull別人的代碼，但實際情況你可以總是pull張三的庫，然後push給李四等等操作。
本地提交：本地提交好處主要有3點：一， 斷網提交 。二， 小步提交。可以對自己的階段成果有跟蹤，並且提高每次變更的安全性。三，本地庫。這個和斷網提交是同一個實現，但從需求角度出發則略有不同，主要是說即使只有自己一個人開發項目，也可以輕易的讓自己的代碼有版本跟蹤，而不需要去費力建個什麼svn server。四，本地回滾。這個其實是由於本地庫的存在而產生的，但可以減少中央庫上的冗餘版本
分支策略：在Git實際開發中分支的分離和merge是屬於日常操作，開啓和合並分支成本相比SVN要小得多：SVN是複製一份代碼到分支目錄，Git則是在分支點做一下標記。隨便一次衝突就會自動產生分支，所以大家每天都在與分支打交道。這便是弱化了分支的概念，由於分支成本很小，因此使得按功能分支的開發模式（每個分支一個功能，開發完了再merge到主幹）變得非常簡單，大家可以完全不需要再因爲擔心SCM成本太高而選用主幹開發模式（所有功能都在主幹上開發，到了發版本前再分離出分支）。
兩者的工作流對比：
svn模式
寫代碼。
從服務器拉回服務器的當前版本庫，並解決服務器版本庫與本地代碼的衝突。
將本地代碼提交到服務器。
git模式
寫代碼。
提交到本地版本庫。
從服務器拉回服務器的當前版本庫，並解決服務器版本庫與本地代碼的衝突。
將遠程庫與本地代碼合併結果提交到本地版本庫。
將本地版本庫推到服務器。
對比可以看出：分佈式版本管理僅僅是增加了本地庫這個概念，其餘的概念與集中管理並無區別。——但是 svn 在與服務器同步之前無法提交代碼，因而本地修改更容易出問題。
總結一下：
當研發成本比較低，協作開發人數不多，開發人員對於版本管理的水平參差不齊的時候，或者對於代碼的安全性要求更高一點的時候，適合用svn。
而對於很多人蔘與開發，代碼量比較大，或者高頻次協作，跨公司，跨地域合作的情況下，更適合用git。