Git簡介

Git簡介

 

一、本地版本控制系統

很久以前人們就開始考慮版本控制的問題，因為簡單的透過複製整個專案目錄的方式來儲存不同的版本雖然操作簡單，但是缺點顯而易見。為解決此類問題，人們開發出本地版本控制系統，大多是採用簡單的資料庫方式來記錄檔案的歷史更新差異，如圖：

二、集中化的版本控制系統

很快人們遇到一個新的問題，即如何讓不同系統下的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱CVCS ）應運而生，諸如CVS、SVN等，它們的共同點是都有一個單一的管理伺服器，儲存整個專案的檔案歷史，而協同工作的開發者透過客戶端連線到伺服器，取出最新的檔案或者提交自己的更新。

這麼做最顯而易見的缺點是中央伺服器的單點故障。若是當機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。
事分兩面，有好有壞。這麼做最顯而易見的缺點是中央伺服器的單點故障。如果當機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。要 是中央伺服器的磁碟發生故障，碰巧沒做備份，或者備份不夠及時，就還是會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄，而被客戶端 提取出來的某些快照資料除外，但這樣的話依然是個問題，你不能保證所有的資料都已經有人事先完整提取出來過。本地版本控制系統也存在類似問題，只要整個項 目的歷史記錄被儲存在單一位置，就有丟失所有歷史更新記錄的風險。

三、分散式版本控制系統

分散式版本控制系統（ Distributed Version Control System，簡稱DVCS ）。在這類系統中，諸如Git，Mercurial，Bazaar 還有Darcs 等，客戶端並不只提取最新版本的檔案快照，而是把原始的程式碼倉庫完整地映象下來。這麼一來，任何一處協同工作的歷史用的伺服器發生故障，事後都可以用任何一個映象出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對程式碼倉庫的完整備份。

四、檔案差異版本控制

CVS、SVN等系統進行版本控制的原理為每次都記錄有哪些檔案作了更新，其控制原理如圖所示：

五、直接快照版本控制

Git並不儲存這些前後變化的差異資料。實際上，Git更像是把變化的檔案作快照後，記錄在一個微型的檔案系統中。每次提交更新時，它會縱覽一遍所有檔案的指紋資訊並對檔案作一快照，然後儲存一個指向這次快照的索引。為提高效能，若檔案沒有變化，Git不會再次儲存，而只對上次儲存的快照作一連線。

如上圖所示，沒有改變的做一個連結，用虛線表示。

六、四個狀態和三個區域

Git內部只有三個狀態，分別是未修改unmodified、修改modified、暫存staged。對於沒有加入Git控制的檔案，可以視為第四種狀態未跟蹤untracked。

untracked:未跟蹤，此檔案在資料夾中，但並沒有加入git庫，不參與版本控制。 透過”git add”,”git commit”可將它置入跟蹤庫。
unmodify：檔案已在庫中，未修改，即版本庫中的檔案快照內容與資料夾中完全一致。這種型別的檔案有兩個去處，如果它被修改，而成為modified。如果使用”git rm”移出版本庫，則成為untracked檔案。
modified：檔案已修改，僅僅是修改，並沒有進行其它操作。這個檔案也有兩個去處，透過”git add”可進入暫存(staged)狀態，使用”git checkout”則丟棄修改，返因到unmodify狀態。這個checkout很好理解，就是取出庫中檔案，覆蓋當前檔案吧。
staged：暫存狀態。執得”git commit”則將修改同步到庫中，這時庫中的檔案與本地檔案又一致了，於是檔案是unmodify狀態。執行”git reset HEAD filenam”取消暫存，檔案狀態變為modified。

Git檔案流轉有三個區域，分別是工作區域、索引區域、本地資料區域。工作樹中的檔案新增到git版本控制索引中，則git開始對檔案進行跟蹤監控。索引區域也可以理解為資料暫存區域，當提交操作時，暫存區域的資料被記錄到本地資料倉儲中。提示有人叫暫存區為索引區，其實都一樣。


參考文章：http://blog.csdn.net/luckarecs/article/details/7427792