1.1 關於版本控制
什麼是版本控制?我爲什麼要關心它呢?版本控制是記錄一個或者若干文件的變化,以便於將來查看各種特定版本修訂情況的系統.在本書中所展現的例子中,我們僅對保存着軟件源代碼的文本文件做版本控制管理
集中式版本控制系統
集中化的版本控制系統(Centralized Version Control System)簡稱CVCS,這類系統,諸如CVS,SubVersion以及 PerForce等,都有一個單一的集中管理的服務器,保存着所有文件的修訂版本,而協同工作的人們通過客戶端連接到這臺服務器,取出最新的文件或者提交更新.多年以來這已經成爲版本控制系統的標準做法.
這種做法帶來了許多好處,特別是相對於老式的VCS來說.現在,每個人可以在一定程度上看到項目中的其他人正在做什麼.而管理員也可以輕鬆的掌控每個開發者的權限,並且管理一個CVCS要遠比在各個客戶端上維護本地數據來的容易
事分兩面,有好有壞.這麼做最顯而易見的缺點是中央服務器的單點故障.如果宕機一小時,那麼在這一小時內,誰都無法提交更新,也無法協同工作,,要是中央服務器的磁盤發生故障,,碰巧沒做備份,,或者備份不夠及時,就會有丟失數據的風險.最壞的情況是丟失整個項目的所有歷史更改記錄.而被客戶端偶然提取出來的某些快照就撐了恢復數據的希望.但這樣的話依然是個問題,你不能保證所有的數據都有人事先完整提取出來過,本地的版本控制也存在類似的問題,只要整個項目歷史記錄被保存在單一的位置,就有丟失歷史更新記錄的風險.
分佈式版本控制系統
於是分佈式版本控制系統(Distributed Version Control System,簡稱DVCS)就出現了,在這類系統中,像Git,Mercurial,Bazaar以及Darcs等,客戶端並不只是提取最新版本的文件快照,而是吧代碼倉庫完整的複製下來,這麼一來,任何一處協同工做的服務器發生故障,事後都可以任何一個鏡像下來的本地倉庫恢復,因爲每一次提取操作,實際上都是一次對代碼倉庫的完成備份.
更進一步,許多這類系統都可以指定若干不同的遠端代碼倉庫進行交互,藉此,你就可以在一個項目中,分別和不同小組的人相互協作.你也可以根據需要設定不同的協作流程,比如層次模式的工作流.而這是在以前的集中式版本控制系統中無法實現的.
1.2 Git
Git是怎樣的一個系統呢
直接記錄快照,而非差異比較
Git和其他版本控制系統的主要區別在於,Git只關心文件數據的整體是否發生變化,而大多數系統則只關心文件內容的具體差異.這類系統(CVS,SubVersion,Perforce,Bazaar等)每次記錄有哪些文件做了更新,以及都更新了什麼內容.Git並不保存這些前後變化的具體差異.實際上,Git更像是把變化的文件作爲快照後,記錄在一個微型的文件系統中.每次提交更新時,它會總覽一遍所有文件的指紋信息並對文件做一快照,然後保存指向這一快照的索引,爲提高性能,若文件沒有變化,Git不會再次保存,而只對上一次保存的快照做一次鏈接
近乎所有的操作都是本地執行
因爲本地保存着所有版本的歷史更新
例如,如果要瀏覽項目歷史更新摘要,Git不用跑到外面的服務器上去取回數據來,而直接從本地數據庫中提取出來展示給你看
時刻保存數據的完整性
在保存到GIt之前,所有的數據都要進行內容的校驗和計算,並將此結果作爲數據的唯一標識和索引,換句話說,不可能在你修改了文件或者目錄後,Git一無所知,這項特性作爲Git設計哲學,建在整體架構的最底層.所以,如果文件在傳輸時變得不完整,或者磁盤損壞導致文件數據缺失,Git都能立即察覺.
多數操作權限添加數據
常用的Git操作大多僅僅是吧數據添加到數據庫,因爲任何一種不可逆的操作,比如刪除數據,都會使回退或重現歷史版本變得尤其困難,在Git中,一旦提交快照之後就完全不用擔心數據丟失,特別是養成定期推送到其他倉庫的習慣的話.
這種高可靠性令我們的開發工作安心不少,儘管去做各種實驗性的嘗試好了,再怎樣也不會弄丟數據,
文件的三種狀態
任何一個文件,在Git中都有三種狀態:已提交(committed),已修改(modified),和已暫存(staged).已提交表示該文件已被安全的保存在本地數據庫中了;已修改表示已經修改了某個文件,但是還沒有提交保存;已暫存表示已經把下次要提交的文件保存在清單中.
每個項目都有一個Git目錄(譯註:如果git clone出來的話,就是其中的.git目錄;如果git clone -bare的話,新建的目錄本身就是git目錄),它是git用來保存元數據和數據對象的地方.該目錄非常重要,每次克隆鏡像倉庫的時候,這些文件其實都是從git目錄中壓縮對象數據庫中提取出來的,接下來就可以在工作目錄中對這些文件進行編輯
