文章目錄
什麼是版本控制系統
概念
版本控制是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統。你可以對任何類型的文件進行版本控制。
版本控制（Revision control）是一種在開發的過程中用於管理我們對文件、目錄或工程等內容的修改歷史，方便查看更改歷史記錄，備份以便恢復以前的版本的軟件工程技術。
版本控制可以做什麼？
自動生成備份
知道改動的地方
隨時回滾
舉例理解:
如果你是位圖形或網頁設計師，可能會需要保存某一幅圖片或頁面佈局文件的所有修訂版本（這或許是你非常渴望擁有的功能），採用版本控制系統（VCS）是個明智的選擇。
有了它你就可以將選定的文件回溯到之前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，你可以比較文件的變化細節，查出最後是誰修改了哪個地方，從而找出導致怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等。
使用版本控制系統通常還意味着，就算你亂來一氣把整個項目中的文件改的改刪的刪，你也照樣可以輕鬆恢復到原先的樣子。 但額外增加的工作量卻微乎其微。
主流的版本控制器有如下這些：
Git
SVN（Subversion） - 集中式的額版本控制系統
CVS（Concurrent Versions System）
VSS（Micorosoft Visual SourceSafe）
TFS（Team Foundation Server）
Visual Studio Online
版本控制產品非常的多（Perforce、Rational ClearCase、RCS（GNU Revision Control
System）、Serena Dimention、SVK、BitKeeper、Monotone、Bazaar、Mercurial、SourceGear
Vault），現在影響力大且使用廣泛的是 Git 與 SVN
版本控制系統的分類
本地版本控制系統
許多人習慣用複製整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。 這麼做唯一的好處就是簡單，但是特別容易犯錯。 有時候會混淆所在的工作目錄，一不小心會寫錯文件或者覆蓋意想外的文件。
爲了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的數據庫來記錄文件的歷次更新差異。
簡單的說：（記錄文件每次的更新，可以對每個版本做一個快照，或是記錄補丁文件，適合個人用，如RCS。)
其中最流行的一種叫做 RCS，現今許多計算機系統上都還看得到它的蹤影。 RCS 的工作原理是在硬盤上保存補丁集（補丁是指文件修訂前後的變化）；通過應用所有的補丁，可以重新計算出各個版本的文件內容。
集中化的版本控制系統
下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？ 於是，集中化的版本控制系統（Centralized Version Control Systems，簡稱 CVCS）應運而生。
這類系統，諸如 CVS、Subversion 以及 Perforce 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。 多年以來，這已成爲版本控制系統的標準做法。
這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。 現在，每個人都可以在一定程度上看到項目中的其他人正在做些什麼。 而管理員也可以輕鬆掌控每個開發者的權限，並且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。
這麼做最顯而易見的缺點是中央服務器的單點故障。 如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。 如果中心數據庫所在的磁盤發生損壞，又沒有做恰當備份，毫無疑問你將丟失所有數據——包括項目的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。 本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。
分佈式版本控制系統
分佈式版本控制系統（Distributed Version Control System，簡稱 DVCS） 在這類系統中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客戶端並不只提取最新版本的文件快照， 而是把代碼倉庫完整地鏡像下來，包括完整的歷史記錄。 這麼一來，任何一處協同工作用的服務器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。 因爲每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。
所有版本信息倉庫全部同步到本地的每個用戶，這樣就可以在本地查看所有版本歷史，可以離線在本地提交，只需在連網時 push 到相應的服務器或其他用戶那裏。
由於每個用戶那裏保存的都是所有的版本數據，只要有一個用戶的設備沒有問題就可以恢復所有的數據，但這增加了本地存儲空間的佔用
git是什麼
Git（讀音爲/gɪt/）是一個開源的分佈式版本控制系統，可以有效、高速地處理從很小到非常大的項目版本管理。
Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。
必看祕籍：https://git-scm.com/book/zh/v2/
git 的特點
速度
簡單的設計
對非線性開發模式的強力支持（允許成千上萬個並行開發的分支）
完全分佈式
有能力高效管理類似 Linux 內核一樣的超大規模項目（速度和數據量)
git和其他版本控制器的差異
直接記錄快照，而非差異比較
Git 和其它版本控制系統（包括 Subversion 和近似工具）的主要差別在於 Git 對待數據的方法。 從概念上來說，其它大部分系統以文件變更列表的方式存儲信息，這類系統（CVS、Subversion、Perforce、Bazaar 等等） 將它們存儲的信息看作是一組基本文件和每個文件隨時間逐步累積的差異 （它們通常稱作 基於差異（delta-based） 的版本控制）
Git 不按照以上方式對待或保存數據。反之，Git 更像是把數據看作是對小型文件系統的一系列快照。 在 Git 中，每當你提交更新或保存項目狀態時，它基本上就會對當時的全部文件創建一個快照並保存這個快照的索引。 爲了效率，如果文件沒有修改，Git 不再重新存儲該文件，而是隻保留一個鏈接指向之前存儲的文件。 Git 對待數據更像是一個 快照流。
這是 Git 與幾乎所有其它版本控制系統的重要區別。 因此 Git 重新考慮了以前每一代版本控制系統延續下來的諸多方面。 Git 更像是一個小型的文件系統，提供了許多以此爲基礎構建的超強工具，而不只是一個簡單的 VCS。
近乎所有操作都是本地執行
在 Git 中的絕大多數操作都只需要訪問本地文件和資源，一般不需要來自網絡上其它計算機的信息。 如果你習慣於所有操作都有網絡延時開銷的集中式版本控制系統，Git 在這方面會讓你感到速度之神賜給了 Git 超凡的能量。 因爲你在本地磁盤上就有項目的完整歷史，所以大部分操作看起來瞬間完成。
舉個例子，要瀏覽項目的歷史，Git 不需外連到服務器去獲取歷史，然後再顯示出來——它只需直接從本地數據庫中讀取。 你能立即看到項目歷史。如果你想查看當前版本與一個月前的版本之間引入的修改， Git 會查找到一個月前的文件做一次本地的差異計算，而不是由遠程服務器處理或從遠程服務器拉回舊版本文件再來本地處理。
這也意味着你在離線或者沒有 VPN 時，幾乎可以進行任何操作。 如你在飛機或火車上想做些工作，就能愉快地提交（到你的 本地 副本，還記得嗎？）， 直到有網絡連接時再上傳。如你回家後 VPN 客戶端不正常，那麼也仍能工作。 使用其它系統的話，做到這些是不可能或很費力的。 比如，用 Perforce 的話，沒有連接服務器時幾乎不能做什麼事；而用 Subversion 和 CVS 的話， 你能修改文件，但不能向數據庫提交修改（因爲你的本地數據庫離線了）。 這樣似乎問題不大，但是你可能會驚喜地發現它帶來的巨大的不同。
Git 保證完整性
Git 中所有的數據在存儲前都計算校驗和，然後以校驗和來引用。 這意味着不可能在 Git 不知情時更改任何文件內容或目錄內容。 這個功能建構在 Git 底層，是構成 Git 哲學不可或缺的部分。 若你在傳送過程中丟失信息或損壞文件，Git 就能發現。
Git 用以計算校驗和的機制叫做 SHA-1 散列（hash，哈希）。 這是一個由 40 個十六進制字符（0-9 和 a-f）組成的字符串，基於 Git 中文件的內容或目錄結構計算出來。 SHA-1 哈希看起來是這樣：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 中使用這種哈希值的情況很多，你將經常看到這種哈希值。 實際上，Git 數據庫中保存的信息都是以文件內容的哈希值來索引，而不是文件名。
Git 一般只添加數據
你執行的 Git 操作，幾乎只往 Git 數據庫中 添加 數據。 你很難讓 Git 執行任何不可逆操作，或者讓它以任何方式清除數據。 同別的 VCS 一樣，未提交更新時有可能丟失或弄亂修改的內容。但是一旦你提交快照到 Git 中， 就難以再丟失數據，特別是如果你定期的推送數據庫到其它倉庫的話。
撤銷操作:
https://git-scm.com/book/zh/v2/Git-%E5%9F%BA%E7%A1%80-%E6%92%A4%E6%B6%88%E6%93%8D%E4%BD%9C#_undoing
git的三種狀態
Git 有三種狀態，你的文件可能處於其中之一： 已提交（committed）、已修改（modified） 和 已暫存（staged）。
已修改表示修改了文件，但還沒保存到數據庫中。
已暫存表示對一個已修改文件的當前版本做了標記，使之包含在下次提交的快照中。
已提交表示數據已經安全地保存在本地數據庫中。
這會讓我們的 Git 項目擁有三個階段：工作區、暫存區以及 Git 目錄。
1.工作區是對項目的某個版本獨立提取出來的內容。 這些從 Git 倉庫的壓縮數據庫中提取出來的文件，放在磁盤上供你使用或修改。
2.暫存區是一個文件，保存了下次將要提交的文件列表信息，一般在 Git 倉庫目錄中。 按照 Git 的術語叫做“索引”，不過一般說法還是叫“暫存區”。
3.Git 倉庫目錄是 Git 用來保存項目的元數據和對象數據庫的地方。 這是 Git 中最重要的部分，從其它計算機克隆倉庫時，複製的就是這裏的數據。
基本的 Git 工作流程
在工作區中修改文件。
將你想要下次提交的更改選擇性地暫存，這樣只會將更改的部分添加到暫存區。
提交更新，找到暫存區的文件，將快照永久性存儲到 Git 目錄
如果 Git 目錄中保存着特定版本的文件，就屬於 已提交 狀態。
如果文件已修改並放入暫存區，就屬於 已暫存 狀態。
如果自上次檢出後，作了修改但還沒有放到暫存區域，就是 已修改 狀態。