首先介紹幾個版本控制軟件相互比較的重要依據，更詳細的比較請參考文中鏈接：
* 版本庫模型（Repository model）:描述了多個源碼版本庫副本間的關係，有客戶端/服務器和分佈式兩種模式。在客戶端/服務器模式下，每一用戶通過客戶端訪問位於服務器的主版本庫，每一客戶機只需保存它所關注的文件副本，對當前工作副本（working copy）的更改只有在提交到服務器之後，其它用戶才能看到對應文件的修改。而在分佈式模式下，這些源碼版本庫副本間是對等的實體，用戶的機器出了保存他們的工作副本外，還擁有本地版本庫的歷史信息。
* 併發模式（Concurrency model）:描述了當同時對同一工作副本/文件進行更改或編輯時，如何管理這種衝突以避免產生無意義的數據，有排它鎖和合並模式。在排它鎖模式下，只有發出請求並獲得當前文件排它鎖的用戶才能對對該文件進行更改。而在合併模式下，用戶可以隨意編輯或更改文件，但可能隨時會被通知存在衝突（兩個或多個用戶同時編輯同一文件），於是版本控制工具或用戶需要合併更改以解決這種衝突。因此，幾乎所有的分佈式版本控制軟件採用合併方式解決併發衝突。
* 歷史模式（History model）：描述瞭如何在版本庫中存貯文件的更改信息，有快照和改變集兩種模式。在快照模式下，版本庫會分別存儲更改發生前後的工作副本；而在改變集模式下，版本庫除了保存更改發生前的工作副本外，只保存更改發生後的改變信息。
* 變更範圍（Scope of change）：描述了版本編號是針對單個文件還是整個目錄樹。
* 網絡協議（Network protocols）：描述了多個版本庫間進行同步時採用的網絡協議。
* 原子提交性（Atomic commit）：描述了在提交更改時，能否保證所有更改要麼全部提交或合併，要麼不會發生任何改變。
* 部分克隆（Partial checkout/clone）：是否支持只拷貝版本庫中特定的子目錄。
以下介紹幾種常見的版本控制管理工具。
1、VSS-- Visual Source Safe此工具是Microsoft提供的，是使用的相當普遍的工具之一，他可以與VS.net進行無縫集成，成爲了獨立開發人員和小型開發團隊所適合的工具，基本上Window平臺上開發的中小型企業，當規模較大後，其性能通常是無法忍受的，對分支與並行開發支持的比較有限。
其相關的外掛支持工具爲SAW,SOS.
詳細請見: http://msdn.microsoft.com/zh-cn/library/ms181038(en-us).aspx
2、CVS--Concurrent Versions System，
此工具是一個開源工具，與後面提到的SVN是同一個廠家：Collab.Net提供的。
CVS是源於unix的版本控制工具，對於CVS的安裝和使用最好對unix的系統有所瞭解能更容易學習，CVS的服務器管理需要進行各種命令行操作。目前，CVS的客戶端有winCVS的圖形化界面，服務器端也有CVSNT的版本，易用性正在提高。
此工具是相當著名，使用得相當廣泛的版本控制工具之一，使用成熟的“Copy-Modify-Merge"開發模型，可以大大的提高開發效率，適合於項目比較大，產品發佈頻繁，分支活動頻繁的中大型項目。
可以與Eclipse等流行工具進行集成開發。
詳細請見：http://ximbiot.com/
3、SVN --CollabNet Subversion
此工具是在CVS 的基礎上，由CollabNet提供開發的，也是開源工具，目前越來越受到大家的歡迎，估計將來可能會成爲最著名，使用最廣泛的工具。
他修正cvs的一些侷限性，適用範圍同cvs，目前有一些基於SVN的第三方工具，如TortoiseSVN,是其客戶端程序，使用的也相當廣泛。在權限管理，分支合併等方面做的很出色，他可以與Apache集成在一起進行用戶認證。
不過在權限管理方面目前還沒有個很好用的界面化工具，SVNManger對於已經使用SVN進行配置的項目來說，基本上是無法應用的，但對於從頭開始的項目是可以的，功能比較強大，但是搭建svnManger比較麻煩。
是一個跨平臺的軟件，支持大多數常見的操作系統。作爲一個開源的版本控制系統,Subversion 管理着隨時間改變的數據。 這些數據放置在一箇中央資料檔案庫中。 這個檔案庫很像一個普通的文件服務器, 不過它會記住每一次文件的變動。 這樣你就可以把檔案恢復到舊的版本, 或是瀏覽文件的變動歷史。Subversion 是一個通用的系統, 可用來管理任何類型的文件, 其中包括了程序源碼。
大家可以通過：http://blog.csdn.net/zssureqh/article/details/39117601來進行進一步的瞭解。
背景：
原本在學校跟隨導師做項目的時候，就一直在使用版本管理，主要是用來記錄項目的修改，項目成員之間的溝通和交流。使用的服務端是Visual SVN，客戶端是TortoiseSVN，常用的TortoiseSVN指令也僅限於SVN Update和SVN Commit，前者用來從服務器更新，以期望查看其他同學的修改，後者用來將自己的修改提交到服務器，使得團隊共享修改。由於項目組中的成員比較少，主要的代碼修改也只有我一人完成，因此TortoiseSVN也就淪爲了記錄我修改本地代碼過程的工具。其實這與我平時寫工作日誌（word格式）、代碼中添加註釋（註釋中一般會出現修改原因、修改者、修改時間、備註）的習慣有一些冗餘。
隨後進入職場，接觸的項目越來越大、開發者越來越多，就慢慢開始瞭解TortoiseSVN的其它功能。例如查看文件修改日誌Show log、回滾已提交的修改操作Revert、創建分支Branch/Tag、創建補丁Create patch等。在逐漸熟悉和使用的情況下，逐漸感覺到TortoiseSVN似乎還缺少一點什麼功能？比如下述場景就經常發生：我從項目SVN服務器拷貝自己負責的代碼到我的本本，然後按照項目計劃開始修改自己的模塊（此時就像在本地開發調試一樣），但是突然臨時接到上級指示，有一個緊急的Bug要處理。此時我只能先創建補丁文件（Create patch），然後將目前的修改回滾到初始狀態（即我從SVN服務器拷貝時的版本），如是我才能開始修改緊急的bug。等待修補完成後，再將先前的patch文件應用回來。這裏面我會同時做好相應的工作記錄（word文檔），這裏面就會記錄我初始修改模塊時的相關步驟和細節，記錄bug修補的過程，然後接着記錄模塊的修改。如此，結合TortoiseSVN的提交日誌和我的word工作文檔，我才能精確的定位我開發過程中的任意時刻——方便後續思路的整理和延續，如下圖所示：如果每次TortoiseSVN提交的時間粒度是按照黃色箭頭所示，那麼中間的紅色修改我只能在我的word工作日誌中查看，但是word中畢竟記錄的是思路，具體的代碼文件我只能手動拷貝到word日誌中記錄的相應位置，或者創建patch文件保存到制定位置，如果TortoiseSVN提交的時間粒度是途中箭頭所示，那麼這與word日誌的工作幾乎重複，可以達到隨意定位修改的目的，但是需要注意的是，在團隊開發中，如此頻繁的TortoiseSVN提交時絕對不可能的，一是SVN服務器要求完整的功能修改完成後才能提交，而是如此頻繁的提交會增加服務器負擔，也會使得自己不完整的代碼模塊影響整個項目的功能。
看到這裏，你是不是覺得好複雜，好麻煩，但是對於碼農來說，良好的記錄和註釋是必須的，這樣你才能更好的對自己的代碼負責。這種開發狀態我已經堅持了多年，也習以爲常了，直到某一天我接觸了Git後，我才恍然發現，原來還有一種所謂的分佈式版本管理工具，可以記錄我的本地修改。真是令我喜大普奔。
下面介紹一下怎麼利用Git來管理本地的代碼修改。
Git管理本地代碼修改：
1）Git與SVN的區別：
關於兩者的分析和討論早已遍佈各大論壇、貼吧，這裏我不評價兩者孰優孰劣。僅從自己實際的代碼開發工作，從提高我本人代碼開發效率的角度來說一下我對兩者的看法。正如背景中所述，SVN的使用已有多年，簡單的來說就是有一個服務器會存儲你對代碼的修改，這裏的修改必須是你確定提交（Commit）到服務器的。對於兩次提交的間隔粒度完全取決於開發者本人，如果僅僅是利用SVN來管理自己的代碼開發記錄，你完全可以隨意提交以期望來記錄自己完整的開發流程（這種方式在團隊合作中是堅決不允許的）。SVN的結構分爲版本庫和工作副本，版本庫就是放在服務端的“數據庫”用來記錄你每次的提交，記錄的內容包括所有版本庫控制範圍內的文件的改動；工作副本就是你自己本機中的代碼工程，它是服務器中代碼工程的一個拷貝，SVN將版本庫和工作副本存放在不同的位置。具體的示意圖如下（自己思路的直接體現，可能不一定完全符合SVN的工作過程，但是大意是正確的，便於大家理解）：
“svn有兩種存儲方式：BDB和FSFS，目前用的最多的是FSFS方式，這種方式的話，一般是存儲在\db\revs文件夾下，裏面有一堆以版本號命名的文件，如：0、1、2、3、4......，那個就是我們的工程文件。svn先把0版本的狀態壓縮成1個文件，然後每次版本更新時就針對變動的部分做一個壓縮文件，每次都是增加一個增量包，最後在服務器上能看到文件名爲從0開始到最終版本的一系列文件”
“SVN服務器端不是簡單將上傳的文件一個一個存放起來的，SVN服務器端默認採用的FSFS格式是將每次commit的內容增量方式存放的，每個增量包存成1個文件，這個增量包中包括了這次commit的全部數據。也就是說你不可能在服務器端存放該版本庫的文件夾下找到你上傳的某個文件”。
至此我們就明白了SVN服務端的結構。至於客戶端就沒什麼難的了。就是通過網絡協議將服務端的版本庫下載到本地，存儲在.svn目錄下，除此以外的就是自己的工程文件了（如果你是從遠端SVN服務器下載的別人的工程，那麼就是別人的工程文件）。.svn中記錄的是你從SVN服務器下載時刻時服務器工程文件的狀態，再下一次提交時刻，會與SVN服務器通訊來查看服務器和你本地兩端的修改狀況。
2）Git管理本地代碼修改
第一步，Git的版本庫和工作副本在同一目錄下，叫做.git。安裝完Git後，可以直接在任意目錄下單擊右鍵，選擇Git Init Here，建立Git版本庫，即.git文件夾。（謹記：這是我們在本地建立的版本庫，壓根兒沒有服務器毛關係啊，^_^。）
第二步，直接將我們需要管理的本地工程拷貝到.git同目錄下。隨後我們想正常開發一樣打開工程進行操作即可，直到我想保存一下修改狀態時，我們就可以轉到第三步。
第三步，在工程文件夾中右鍵，選擇Git Gui，會彈出管理窗口，這裏會顯示我們所做的修改，在紅色框中列出的是我們做過修改的文件，橙色框中可以看到所做的修改。綠色框中顯示的是修改的緩衝區，通過在紅色框中選擇指定文件進入到綠色的緩衝區後，我們可以單擊黃色按鈕“提交”，至此本次我們對本地文件的修改記錄就已經提交了。
第四步，在工程文件夾右鍵，選擇Git History，我們既可以看到本地的此次修改記錄。
至此我們就很容易的實現了對本地代碼修改的記錄，而這整個過程中，根本沒出現服務器。這是與SVN最大的區別。