首先我表明一個根本的立場，我個人更喜歡用Git，但是，這僅僅是一個個人偏好。當我們需要將一種技術方案帶給整個團隊的時候，並不是由我們的個人偏好作為主要決定因素，而應該充分去權衡利弊，選擇對團隊，對公司更有效率的方案。拋開個人立場，理性評估利弊，可能才是我認可的一個資深程序員，或者一個架構師的本分。
我所在的團隊，現在選用的技術方案是Git作為全公司的版本控制系統，我們一共有差不多20個程序員，使用五種以上的程序設計語言，研發維護四個左右的項目，屬於小型創業公司中，研發規模中等偏上的企業。使用Git作為版本控制系統，在我加入公司之前，已經是既成事實了，在我聽說這一點的時候，我非常高興，因為我說過，我喜歡Git。
上周五，我們公司新來的工程師，在周會上分享Git，有個同事挑戰道，為什麼Git比SVN更好？這個問題，如果是問我個人的話，我可能會有很多的理由，但是，就像我一貫的思維模式，說服別人的時候，必須給出足夠令人信服的原因，不能使用主觀因素去說服別人，那樣只能引起爭論。
對於，“為什麼Git比SVN更好”這個問題，我真的很想給出一個肯定的答案，但是，我在探尋答案的過程中，遇到了困難。於是，我來嘗試一下站在反面的立場來給出一份答卷，然後，我們再反過來辯論，於是就有了本文的題目。
SVN到底有什麼優點
廣泛的群眾基礎。從我開始使用版本控制系統，我用的就已經是SVN了，所以，想要追溯SVN到底從什麼時候開始，不得不求助於維基百科，我發現，SVN首個正式版本，可以追溯到2000年，距今已經十五年歷史了。在Github成為大熱門之前，SVN基本處於一統天下的地位。幾乎所有的公司都在使用SVN作為內部的版本控制系統，Google Code更是掀起了開源軟件的浪潮，一時間，幾乎全世界的程序員，都在使用SVN。
我敢說，我們公司目前招聘的程序員，還沒有沒用過SVN的。這意味著，如果公司使用SVN的話，他們快速上手的概率，是非常高的。現在中國中小企業和創業企業，程序員招聘的困難程度，我不想多闡述——誰負責，誰頭疼——如果使用SVN的話，學習版本控制系統用法這種事情，不會成為你腦海裡的一個問題。
優異的跨平台支持 。年齡大這種事情，並非總是缺點，在跨平台支持這個角度，就會成為優勢。十五年來，SVN幾乎積累了所有平台上優秀的客戶端軟件。Windows平台的TortoiseSVN的成功，簡直無需贅述，甚至有程序員認為，TortoiseSVN就是SVN本身，一提到小烏龜，每個碼農都會心一笑。而且，SVN本身的命令行客戶端，就已經非常簡潔好用了。跨平台簡直毫無任何可以挑剔的地方。
簡單易用。我個人認為，SVN的易用性是無與倫比的。我剛入職騰訊的第一年，身邊的程序員，是把SVN當成雲端文件夾用的。整個部門，只有一個版本庫，一個項目文件夾，所有的項目代碼仍在trunk裡面，需要開新項目，就在trunk裡加一個文件夾。就算SVN被誤用到這種程度，它依然沒有給整個研發過程帶來任何大的麻煩，一切都井井有條。你要學會的，就是在小烏龜裡點點鼠標而已。
後來，部門逐步擴大，文檔增多，為了保護文檔不丟失，部門運維自己架設了一個SVN服務器，讓所有非程序員成員，都用SVN管理文檔，各種需求，設計稿，統統用SVN管理，這個切換過程幾乎沒花什麼時間，就是簡單地給一些非技術同事培訓了一下，一切都平滑異常。讓五、六十號不懂技術的人，一下子用上SVN，足見其簡單了吧。
功能完善穩定。從過去七年（此時是2015年）的開發經歷來看，我還沒遇到過什麼SVN不能處理的研發管理模型。特指在中國，公司制的研發團隊管理場景下。SVN本身建議的研發流程模型，已經足足夠夠了，trunk用於代碼主干，branches用於特性開發，tag用於發布快照，一切都流暢自然。
我所在的團隊，經過幾年的摸索和磨合，已經形成了非常流暢順滑的研發流程。有新任務來了，開分支，天天早上第一件事，同步主干變更（sync trunk），任務完成後，分支測試，測試完畢後回歸主干（reintegration），完畢後集成測試，測試通過後，打tag，然後用內部自研上線系統，tag全量代碼發布，最後分支負責人刪除掉用過的分支。尤其配合SVN 1.5以後出現的merge tracking功能特性，連沖突都是很偶然的事件了。
SVN經過15年左右的研發，功能異常完善，而且非常穩定，你熟知的命令和參數，就幾乎一直保持著你熟知的那個狀態，沒有附加學習成本，最難能可貴的是，SVN一直在持續更新，改善效率。
Git 相對SVN來說，有什麼缺點？
高昂的學習成本。不要睜著眼睛跟我說，Git學習很簡單啊，“學習很簡單”這一個主觀感受，也即，你覺得簡單，只能代表你一個人的感受，如果整個團隊只有你一個人，或者你們團隊奉行一種精英文化，不是精英不招聘的話，你們所有人，可能都覺得學習Git很簡單。但是如果是一家剛剛創業的小公司，或者經營數年的中小企業，考慮其本身能從市場上獲取到的人才的程度，你不得不考慮他們的接受能力。固然，公司可以花力氣去培訓，可是培訓的時間和代價，本身就構成了“學習成本”。
拙劣的跨平台支持。對於Windows，尤其不友好。但是請注意，Windows仍然是世界上使用最廣泛的操作系統，我相信，大多數基層程序員也仍然在Windows環境下工作，那麼Git那近乎故意的Windows不友好，不知道到底是為了什麼。無論GitHub做了什麼，各種IDE做了什麼，在Windows下使用Git，其體驗仍然是非常間接，而且不方便的。
糟糕的抽象，復雜的結構。要想用好Git，用戶必須理解幾個很特殊的東西，一個是分布式的結構，另一個是Git存儲版本的原理。這對於沒空去理解他的人們來說，很不友好，你幾乎不能憑著直覺去使用Git，那樣幾乎都會把事情搞得一團糟。另外，公司裡非技術的同事，幾乎沒法使用Git工作，比如我們公司的設計師，試圖使用Git來管理設計稿，並進行協作，實際體驗是很糟糕的，他們連新建版本庫都不會。還不用提Git其實對二進制文件並不怎麼友好。
你可以把事情搞得很糟糕。Git整個系統，給用戶提供了極大的自由度，很多操作，我們知道是危險的，但是系統並沒有阻止你操作。比如，你可以把任意分支push到任意分支，比如你可以隨意刪除本地提交歷史裡的commit，比如你可以把多人共享的分支給rebase掉，你可以干出很多匪夷所思的壞事托亂全團隊的速度，你可以惹麻煩，Git本身沒有提供任何保護機制。
一個不是結論的結論
我完全站在SVN的擁泵角度，來闡述上面那些，我會得出這樣的結論，SVN在某些場合，真的比Git更合適，而我覺得，這個結論，也相對是公允的。如果公司研發成本低，研發團隊小，研發人員經驗參差，完全應該考慮直接使用SVN，這可能為你們團隊後續發展，節省大量的時間。
當然，還有一個要考慮的因素是研發內容的特點和研發流程的特點，是否高頻次協作？是否跨公司，跨地域協作？是否海量研發人員參與的開源系統？而就我的經驗看，很少有公司的研發團隊能跟這些東西搭邊，於是SVN理所當然成為更理智的選擇。
Ubuntu 14.04 下搭建SVN服務器 SVN:// http://www.linuxidc.com/Linux/2015-01/111956.htm
CentOS 6.2 SVN搭建 (YUM安裝) http://www.linuxidc.com/Linux/2013-10/91903.htm
CentOS 6.5部署Apache+SVN http://www.linuxidc.com/Linux/2013-12/94315.htm
Apache+SVN搭建SVN服務器 http://www.linuxidc.com/Linux/2013-03/81379.htm
Windows下SVN服務器搭建和使用 + 客戶端重新設置密碼 http://www.linuxidc.com/Linux/2013-05/85189p5.htm
Ubuntu Server 12.04 安裝 SVN 並遷移 Virtual SVN數據 http://www.linuxidc.com/Linux/2013-05/84695.htm
Ubuntu Server搭建SVN服務以及遷移方法 http://www.linuxidc.com/Linux/2013-05/84693.htm
Subversion (SVN) 的詳細介紹：請點這裡
Subversion (SVN) 的下載地址：請點這裡
