網上有很多關於 SVN 和 Git 的比較，但是大多數都是錯誤的，誤解的。

下面給大家列出來一些常見的誤解和真相，雖然這並不能說明哪個系統更好，但是可以幫助你更好的理解兩個系統之間的差異

1.同樣的內容，Git 倉庫遠比 SVN 的小

錯誤：他們的儲存機制實際上是一樣的，所以相差非常小。例外的是二進位制檔案，SVN 反而會遠比 Git 佔用的小，因為 SVN 對二進位制檔案也能進行差異儲存。

2.SVN 建立分支代價非常昂貴。

錯誤：很多人認為 SVN 建立分支是複製整套程式碼，代價很大。實際上從 1.0 版本開始，在 SVN 裡建立分支的代價已經非常非常小，你可以任意建立分支來修復一個小 BUG 或者開發新的功能

3.合併分支時需要指定版本號範圍

錯誤：這是一個過時的誤解，從 1.5 開始就不需要手工指定合併的版本號範圍了，更強大的是從 1.8 版本，還提供了自動合併的功能，大大方便了分支之間的程式碼合併。

4.SVN 需要在每個目錄下都建立一個.svn 的目錄

錯誤：從 1.7 版本開始，已經變為只在根目錄存在.svn 目錄了。

5.沒有人再使用 SVN 了

錯誤：像 FreeBSD 和 LLVM 這種有名的開源專案都還在使用 SVN。實際上，有 47%的開源專案都在使用 SVN，然而使用 Git 的只有 38%。在公司層面就更多使用 SVN 的了，因為 SVN 是真正的標準企業級版本控制系統。

6.分散式的 Git 比集中式的 SVN 更優越

錯誤：他們是平等的。分散式只是實現版本控制的另外一種方法。集中式和分散式兩種方法都有他們的正反兩面，分散式或許適合某些人，但是他也帶來了某些問題，比如：沒有許可權控制；每個人都需要完全 clone 整個倉庫，沒法像 SVN 可以只 checkout 需要的子目錄；沒法鎖定檔案等等問題

7.Git 很適合大專案，SVN 不行

錯誤：在 Git 裡每個人都需要把整個倉庫都 clone 下來，2G 的倉庫或許沒什麼問題，但是到達幾百 G 後呢？你需要 clone 幾百 G 的內容，想想多可怕。有個經典的解決方式就是把 Git 倉庫分為多個小的倉庫，但是這就導致了其他幾個問題：你需要管理多個倉庫；破壞了原有專案的完整性；沒法繼續跟他們一起使用分支；

8.Git 適合大團隊

錯誤：某些工作流適合使用 Git，但是某些情況適合使用 SVN

9.在 SVN 裡，合併總是個痛苦的事

錯誤：SVN 已經能很好的處理合並和衝突，已經成為他很重要的一個功能特性。只有在分支裡重新命名了資料夾或者檔案時會有這種情況，這是個歷史遺留問題。

10.Git 有靈活強大的命令列操作

正確：Git 的設計初衷就是一套低階版本控制系統，允許高階使用者通過命令玩一些黑科技，但是這並不安全，對初學者也不友好。Git 也因為沒有良好的設計和混亂的命令受到了一些指責：這導致加長了學習曲線和大大增加了公司和團隊的成本，特別是大型團隊以及團隊成員水平不一的情況。比如美術、策劃、開發、這類人員，技術水平線不一。

11.Git 的歷史記錄不安全

正確：Git 的官方描述是“笨笨的內容跟蹤”，它並不關心你整個倉庫歷史的完整性和精確性，這導致了重新命名和 git rebase 這類操作很難跟蹤他們的修改記錄。相反 SVN 始終都可以精確的、完整的找到你需要的變動記錄。

12.Git 無法提供細顆粒的許可權控制

正確：因為 Git 分散式的原因，每個人都擁有完整的倉庫程式碼，導致每個人都有完整許可權看到所有的內容。雖然這樣對於開源專案來說沒什麼，但是對於企業來說，這是不可接受的。相反，SVN 可以設定目錄級別的許可權控制，你可以設定他只讀或者讀寫，而且非常適合大型專案。

13.Git 對二進位制檔案儲存不友好

正確：Git 因為分散式原因，無法很好的處理二進位制檔案，他是基於複製模式來管理的，所以並不適合有很多二進位制檔案的專案，比如圖片多的專案。

翻譯來自：svnvsgit
如有翻譯錯誤歡迎指正
希望給那些對 SVN 有誤解的朋友一個參考。
理性的認識兩個不同的工具，合適的使用不同的工具，他們之間沒有誰更好，只有誰更合適。

最後推薦大家一個好用的SVN倉庫：SVNBucket

其他相關教程