1.本地版本控制：
許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區(qū)別。
其中最流行的一種叫做 RCS,它的工作原理是在硬盤上保存補丁集（補丁是指文件修訂前后的變化）；通過應用所有的補丁，可以重新計算出各個版本的文件內(nèi)容。
2.集中化的版本控制系統(tǒng)(CVCS)
不同系統(tǒng)上的開發(fā)者協(xié)同工作？
有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協(xié)同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。 多年以來，這已成為版本控制系統(tǒng)的標準做法。
諸如 CVS、Subversion 以及 Perforce 等
弊：要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。
3.分布式版本控制系統(tǒng)（DVCS）
客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。
何一處協(xié)同工作用的服務器發(fā)生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。 因為每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。像 Git、Mercurial、Bazaar 以及 Darcs 等
更進一步，許多這類系統(tǒng)都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協(xié)作。 你可以根據(jù)需要設定不同的協(xié)作流程，比如層次模型式的工作流，而這在以前的集中式系統(tǒng)中是無法實現(xiàn)的。
很難理解svn和Git的區(qū)別，或者說優(yōu)勢。
svn commit是需要聯(lián)網(wǎng)的，svn中央服務器代碼一旦丟失就很難恢復。
分布式理論上是不需要中央服務器的，A和B是可以直接相互推送的，但是真實開發(fā)中A和B的電腦要相互訪問是很麻煩的。所以出現(xiàn)了github和OSGit。
