1）GIT是分布式的，SVN不是：
這是GIT和其它非分布式的版本控制系統，例如 SVN，CVS等，最核心的區別。如果你能理解這個概念，那么你就已經上手一半了。需要做一點聲明，GIT並不是目前第一個或唯一的分布式版本控制系統。 還有一些系統，例如Bitkeeper, Mercurial等，也是運行在分布式模式上的。但GIT在這方面做的更好，而且有更多強大的功能特征。
GIT 跟SVN一樣有自己的集中式版本庫或服務器。但，GIT更傾向於被使用於分布式模式，也就是每個開發人員從中心版本庫/服務器上chect out代碼后會在自己的機器上克隆一個自己的版本庫。可以這樣說，如果你被困在一個不能連接網絡的地方時，你仍然能夠提交文件，查看歷史版本記錄，創建項 目分支等。
2）GIT把內容按元數據方式存儲，而SVN是按文件：
所有的資源控 制系統都是把文件的元信息隱藏在一個類似.svn,.cvs等的文件夾里。如果你把.git目錄的體積大小跟.svn比較，你會發現它們差距很大。因 為,.git目錄是處於你的機器上的一個克隆版的版本庫，它擁有中心版本庫上所有的東西，例如標簽，分支，版本記錄等。
3）GIT分支和SVN的分支不同：
分支在SVN中一點不特別，就是版本庫中的另外的一個目錄。如果你想知道是否合並了一個分支，你需要手工運行像這樣的命令svn propget svn:mergeinfo，來確認代碼是否被合並。
然而，處理GIT的分支卻是相當的簡單和有趣。你可以從同一個工作目錄下快速的在幾個分支間切換。你很容易發現未被合並的分支，你能簡單而快捷的合並這些文件。
4）GIT沒有一個全局的版本號，而SVN有：
目前為止這是跟SVN相比GIT缺少的最大的一個特征。
5）GIT的內容完整性要優於SVN：
GIT的內容存儲使用的是SHA-1哈希算法。這能確保代碼內容的完整性，確保在遇到磁盤故障和網絡問題時降低對版本庫的破壞。
2、SVN和GIT基本操作對比
1）倉庫創建初始化
在SVN中，倉庫本身的管理和日常應用，使用的是兩套不同的命令。倉庫的創建和備份維護等使用的命令是 svnadmin， 使用svnadmin create來創建一個新的倉庫
在git中，創建一個新的倉庫，可以在一個空目錄下，使用git init來實現，它將創建一個.git目錄用來維護倉庫數據。
在 SVN中，創建倉庫的地方並不是你日常使用的倉庫的地方，你需要在別的地方checkout出特定的倉庫路徑作為你的日常工作的目錄。在git中，倉庫所 在的目錄也就是你的日常工作目錄，沒有服務器端和客戶端之分。（嚴格的說 .git目錄才是倉庫，.git目錄外的地方是你的工作目錄，對於bare project來說，只有git目錄下的內容，工作目錄離得內容還是要checkout出來的）
2）Checkout倉庫
在SVN中，使用SVN checkout(co)來checkout本地或遠程倉庫的代碼
而 對於git來說，盡管也有checkout命令，但是由於你需要在本地擁有倉庫，所以通常從服務器上checkout代碼的第一步是使用git clone來獲取一個倉庫的拷貝，默認的git clone操作同時還會checkout一份遠程倉庫上當前active的分支
在SVN中，其倉庫的管理形式決定了你可以只checkout倉庫中特定路徑/分支下的子目錄，而不是整個倉庫，而git只能checkout整個分支。
3）將文件納入版本管理
在SVN中，使用SVN add，這樣在以后的commit過程中，每次在提交數據之前，svn都會自動根據這些add過的對象的修改情況，構建一個commit tree。
在 git中，因為存在index的概念，要將一個文件納入版本管理的范疇，首先是要用git-update-index –-add將文件納入index的監控范圍，只有更新到index中的內容才會在commit的時候被提交。另外，文件本身的改動並不會自動更新到 index中，每次的任何修改都必須重新更新到index中去才會被提交。 當然，通常會用git add這樣的封裝腳本來調用git-update-index
4）檢查當前狀態
SVN Status 可以顯示當前working tree的文件修改狀態
在git中 git status 命令顯示當前index的狀態和working tree的狀態。
5）提交文件
Git commit操作在git命令中屬於相對簡單的，需要注意的一點就是上面提到的，只有index中的內容才會比提交。
6）刪除文件
在使用Svn rm刪除一個目錄的時候，因為每個目錄下都存在.svn目錄，記錄了這個目錄於服務器端倉庫相關的信息，所以在commit之前，目錄里的其它文件會被刪除，但是目錄及其子目錄並不會被真正刪除，只有commit以后，目錄才會被刪除。
在 git中，同樣，使用git rm 刪除文件。但是git對目錄的處理有些奇怪，如果某個目錄下的所有文件都被刪除以后，該目錄就會被自動刪除，也就是說你無法保留一個空的目錄。你也無法添 加一個空目錄到倉庫里。也就是說git 自動忽略空目錄，不知道這樣做的目的是什么？
7）查看log
svn log命令基本上就是用來查看版本提交時的所填寫的log信息
git log可以做的事情會多很多，畢竟git log是對底層核心命令的再包裝，通過它，不僅可以查看log信息，還可以輸出特定版本的具體變更內容等等信息。
8）版本回溯
在SVN中，不提供任何從倉庫中刪除對象的機制，任何的修改都會導致版本的遞增，所以，如果想丟棄一個修改，你需要做的事是反向diff你的修改，再提交一個新的版本。
在 git中提供了重置committed tree對象索引的機制，所以，你可以通過例如git-reset這樣的操作將當前分支的版本恢復到以前的某個狀態。經常看見的例子就是回溯一個版本，然 后修改內容，再次提交。不過這樣做搞不好很容易出問題。包括在git-push之類的操作時會被reject，需要強行push之類的。
如果只是想放棄一個修改，git的文檔推薦使用git-revert操作，這個操作基本上和SVN的思路是一樣的了，就是提交一個新的版本將需要revert的版本的內容再反向修改回去，版本會遞增，不影響之前提交的內容。
9）放棄當前修改
在SVN中，使用SVN revert對目錄或文件操作都可以將當前工作樹上特定路徑的修改恢復到服務器上的版本，放棄當前的修改。
Git中，對特定文件使用不帶其它參數的git checkout命令可以將文件恢復到index中的狀態，如果你想恢復的特定的版本，那么類似： git checkout HEAD file這樣的操作，將文件恢復到HEAD tree即最近一次提交的狀態。
不過git checkout有個問題，不知道是否是故意這樣設計的，就是即使用git rm刪除的內容，如果沒有提交，git checkout以后也會恢復，包括它在index中的狀態。這點有些不理解。 理論上index上已經記錄這個刪除操作，不應該恢復才對。
Git中還有一種辦法，可以快速徹底的放棄自從上次commit以來的所有變更，git reset –hard HEAD
10）代碼合並
git merge能夠自動記住以前merge過的位置和狀態，這個比較容易理解，因為通過每個分支的head commit可以跟蹤它的對象索引關系。另外，因為其對象管理機制的原因，只能以commit為單位，merge整個分支的所有修改。不能有選擇的 merge部分路徑下的修改。Merge的時候要求index和HEAD是一致的，如果merge成功，內容會直接commit，而工作樹上的修改仍會保 持。（如果失敗，會在工作樹上將需要merge的內容和你已有的修改合並，大概不是你所希望的，所以最好不要這樣做）
merge特定分支的特定版本之前的所有修改，可以通過merge那個版本對應的rev來實現，merge某一段版本區間的修改，考慮到commit需要完整的代碼樹關系，估計靠git merge來做是沒有辦法了，需要自己diff / patch代碼來實現
SVN 的Merge操作不會記住它的merge歷史，換句話說，你可以多次merge同一份代碼，但是他的好處是你可以自由的選擇merge哪一部分、哪一段版 本之間的代碼，應該說他基本等同於是diff和patch的組合。不過因為SVN沒有index的概念，所以merge的操作會和當前working tree上的修改合並在一起。
關於歷史信息方面，因為svn的merge實際是patch文件內容本身，所以，不同分支上的歷史信息不 會在merge以后的主干上體現出來，而git的merge，如果沒有沖突的話，實際是merge commit樹的繼承關系，所以，所有的歷史信息在merge以后的commit中都能夠被索引到。
11）獲取單純的代碼
在svn中，如果不需要任何歷史信息，只想要某個版本純粹的代碼（經常會有這種需求，這樣做本地數據比較小） 那么，使用svn export命令即可以實現。
在git中，似乎沒有這樣的命令，不過，由於git的本地倉庫信息完全維護在project根目錄的.git目錄下，（不像svn一樣，每個子目錄下都有單獨的.svn目錄）。所以，只要clone，checkout然后刪除.git目錄就可以了。