一、本地版本控制系統
很久以前人們就開始考慮版本控制的問題，因為簡單的通過復制整個項目目錄的方式來保存不同的版本雖然操作簡單，但是缺點顯而易見。為解決此類問題，人們開發出本地版本控制系統，大多是采用簡單的數據庫方式來記錄文件的歷史更新差異，如圖：
二、集中化的版本控制系統
很快人們遇到一個新的問題，即如何讓不同系統下的開發者協同工作？於是，集中化的版本控制系統（ 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。
Git文件流轉有三個區域，分別是工作區域、索引區域、本地數據區域。工作樹中的文件添加到git版本控制索引中，則git開始對文件進行跟蹤監控。索引區域也可以理解為數據暫存區域，當提交操作時，暫存區域的數據被記錄到本地數據倉庫中。
