0 前言
全是幹貨的技術殿堂
文章收錄在我的 GitHub 倉庫，歡迎Star/fork：
下載下傳安裝及基本配置
Git官網下載下傳 Git GUI下載下傳安裝成功後，打開，右擊選擇options進行個性化設定：
- 外觀
字型
版本
1 版本控制
1.1 關于版本控制
版本控制是一種記錄一個或若幹檔案内容變化，以便将來查閱特定版本修訂情況的系統。開發中，我們僅對儲存着軟體源代碼的文本檔案作版本控制管理，但實際上，可以對任何類型的檔案進行版本控制。
采用版本控制系統就可以将某個檔案回溯到之前的狀态，甚至将整個項目都回退到過去某個時間點的狀态。
可以比較檔案的變化細節，查出最後是誰修改了哪個地方，進而找出導緻怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等。
使用版本控制系統通常還意味着，就算你亂來一氣把整個項目中的檔案改的改删的删，你也照樣可以輕松恢複到原先的樣子。但額外增加的工作量卻微乎其微。
1.1.1 本地版本控制系統
許多人習慣用複制整個項目目錄的方式來儲存不同的版本，或許還會改名加上備份時間以示差別。這麼做唯一的好處就是簡單。不過壞處也不少：有時候會混淆所在的工作目錄，一旦弄錯檔案丢了資料就沒法撤銷恢複。
為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是采用某種簡單的資料庫來記錄檔案的曆次更新差異
其中最流行的一種叫做 rcs，現今許多計算機系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後，也可以使用 rcs 指令。它的工作原理基本上就是儲存并管理檔案更新檔（patch）。檔案更新檔是一種特定格式的文本檔案，記錄着對應檔案修訂前後的内容變化。是以，根據每次修訂後的更新檔，rcs 可以通過不斷打更新檔，計算出各個版本的檔案内容,像WPS也有類似功能。
1.1.2 集中化的版本控制系統
如何讓在不同系統上的開發者協同工作？
于是，集中化的版本控制系統（ Centralized Version Control Systems，CVCS ）應運而生。
諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的伺服器，儲存所有檔案的修訂版本，而協同工作的人們都通過用戶端連到這台伺服器，取出最新的檔案或者送出更新。多年以來，這已成為版本控制系統的标準做法
每個人都可以在一定程度上看到項目中的其他人正在做些什麼。
管理者也可以輕松掌控每個開發者的權限，并且管理一個 CVCS 要遠比在各個用戶端上維護本地資料庫來得輕松容易。
缺陷
中央伺服器的單點故障。如果當機一小時，那麼在這一小時内，誰都無法送出更新，也就無法協同工作。
要是中央伺服器的磁盤發生故障，碰巧沒做備份，或者備份不夠及時，就會有丢失資料的風險。
最壞的情況是徹底丢失整個項目的所有曆史更改記錄，而被用戶端偶然提取出來的儲存在本地的某些快照資料就成了恢複資料的希望。但這樣的話依然是個問題，你不能保證所有的資料都已經有人事先完整提取出來過。
本地版本控制系統也存在類似問題，隻要整個項目的曆史記錄被儲存在單一位置，就有丢失所有曆史更新記錄的風險。
于是分布式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世！
1.1.3 分布式版本控制系統
像 Git，Mercurial，Bazaar 以及 Darcs 等，用戶端并不隻提取最新版本的檔案快照，而是把代碼倉庫完整地鏡像下來。
優勢
任何一處協同工作用的伺服器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢複。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份
許多這類系統都可以指定和若幹不同的遠端代碼倉庫進行互動。籍此，你就可以在同一個項目中，分别和不同工作小組的人互相協作。你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實作的。