除了人，軟件公司最寶貴的就是代碼了，這些代碼大多儲存在Subversion(以下簡稱”SVN”)這樣開源的版本控制系統（VCS）中。代碼是容易修改和變更的，因此，代碼的備份、歷史追蹤、協同編輯等任務同樣需要版本控制系統完成。從最早本地VCS系統RCS、1990年CVS、2000年SVN，到如今開源世界風頭正健的Git，同語言編輯工具一樣，SVN、Git都是程序員的必備利器。隨著GitHub的流行，很多軟件企業開始計劃轉向Git，但是企業真的準備好了嗎？

從SVN到Git，不僅僅是工具的替換，還有基于其上的工具和一些管理流程的變化。筆者建議：軟件企業需要評估自己當前的狀態和企業文化，認真考慮商業目標，謹慎遷移。我們不妨從以下幾點來探討一下。

陡峭的學習曲線

對于采用SVN進行管理的企業，Git相對復雜，開發工程師的學習曲線并不平緩。

Git的命令分為高層和底層，常用的高層命令約有30多個，與SVN近似。這些操作不能繼承SVN的經驗，因此工程師需要重新學習branch、merge、reset、rebase、revert、pull、fetch等操作命令，需要重新了解哈希值格式的版本號，并用它來進行檢出、比較等。

對于較多使用word、ppt、excel、圖片、IDE等工具的人員來說，從類似FTP的SVN轉向Git ，學習過程會比較痛苦。

缺少角色授權和文件級訪問控制

Git作為開源自由原教旨主義項目，它沒有對版本庫的瀏覽和修改做任何的權限限制。Git的創始人Linus Torvalds 也曾說：“不要讓權限成為政治的理由，Git沒有權限控制。”

由于缺少角色授權，因此在組織結構管理上比較困難。實際操作中，一個Git倉庫用來實現一個項目，大型項目可能需要許多Git倉庫配合實現。在SVN中不同項目在不同目錄中，通過角色授權完成組織結構的規劃。

實現商業目標的軟件企業顯然需要文檔或代碼的訪問授權和控制，目前Git本身是不支持的，需要集成第三方工具實現訪問控制。

有限的目錄檢出功能

SVN是一個中心倉庫和眾多客戶端目錄的關系，因此，SVN用戶都熟悉工作在某個目錄上，在不同的工作計算機上，檢出目錄就可以編輯。然而，Git是一個中心倉庫和眾多客戶端倉庫的關系，你必須工作在整個倉庫上，雖然在Git1.7版本后支持了類似目錄檢出的功能，但仍要先檢出整個倉庫。軟件企業的工程師常同時在多個項目中工作，如果修改一點東西就需要克隆倉庫，對故障響應將有影響。

浪費已投入的開發成本

軟件開發生命周期管理工具的基礎是版本控制系統，各商業軟件開發管理平臺都是基于自主研發的版本控制系統，在此基礎上擴展到項目管理、文檔管理、代碼評審、發布部署、缺陷管理等。基于SVN的開源或自主研發的管理工具非常成熟多樣。遷移到Git，則完全浪費了投入到SVN管理工具的開發成本。

圖形化工具及接口不夠強

雖然Git的圖形工具正在增多，但在Windows下還需要等待這些開源工具增強功能。同時，Git的接口待加強，與眾多工具集成待完善，這些都是需要時間來解決。

目前很多人倡導的Git的優點并非不可替代

Git速度快，但是SVN使用用廉價的高性能主機同樣可以提升速度；Git無需網路也可以工作，但當前穩固的網絡基礎環境和多樣的接入方式，讓SVN并不擔心網絡問題。另外Git方便地處理分支的特性，如果通過控制開發節奏，增加評審，減少分支數量，就可以讓分支合并更簡單快鍵，開發會更有效率，SVN也可以更好地管理分支。 SVN的1.7版本以不兼容舊版客戶端的代價新增和改進了很多功能，開始向Git靠攏，這也使SVN具備Git的特性。

鑒于以上分享的幾個基本點，建議企業謹慎遷移。

筆者對某些場景的命令進行了比較，下表是在Git-1.7 和SVN-1.6上測試的，目的是為了說明SVN的操作經驗在Git上不能直接套用，當然Git也有許多獨特的優秀功能。