先說結(jié)果： git 在有些情況下 確實(shí) 比 svn好用，但并不能取代 svn

第一回合：

git 是分布式的版本控制系統(tǒng)，可以不用固定的 ‘服務(wù)端’ ，更適合研發(fā)人員。而svn是集中管理的版本控制系統(tǒng)，有一個(gè)固定服務(wù)端。但我認(rèn)為要分場合，某些情況下分布式的不一定比集中管理的好，所以這一回合打平了。

第二回合：

git的分支很好用，很強(qiáng)，svn的分支就有點(diǎn)雞肋了，svn的分支就是 svn copy 復(fù)制了一個(gè)完整的項(xiàng)目。 這一回合，git 優(yōu)勢明顯。

第三回合：

提交，更新或合并代碼的時(shí)候經(jīng)常會(huì)報(bào)錯(cuò)，git的提示很 ‘善解人意’，很好解決錯(cuò)誤，svn 的提示就有點(diǎn)差強(qiáng)人意了，這一回合，依然是 git 有優(yōu)勢。

第四回合：

svn 對目錄的權(quán)限控制很好，可以根據(jù)目錄進(jìn)行 更新和提交，這在有些時(shí)候很有用。 而 git 不能對目錄做權(quán)限控制。這一回合 svn 優(yōu)勢明顯。

舉個(gè)例子：

我們公司 研發(fā)人員用的是git ， 美術(shù)和產(chǎn)品都是用的svn，美術(shù)和產(chǎn)品經(jīng)常把需求和資源放到svn，可以根據(jù)目錄下載，不用整個(gè)項(xiàng)目都下載。而且svn在windows 系統(tǒng)下有一個(gè)很出名的軟件 TortoiseSVN ，有中文版的，用起來很方便。

一句話：存在即合理。

個(gè)人經(jīng)歷了CVS、SVN再到Git，個(gè)人傾向于Git，畢竟Git流行起來，自然有它的優(yōu)勢。但是它的劣勢，也是讓我有時(shí)候想用SVN。

下面先來說說SVN和Git是什么？

A. SVN

Apache Subversion（簡稱SVN，svn），一個(gè)開放源代碼的版本控制系統(tǒng)。第一次設(shè)計(jì)并發(fā)布 Subversion 時(shí), 它的主要版本控制策略是集中式的版本控制 (centralized version control)，它有一個(gè)遠(yuǎn)程的主倉庫, 倉庫中存放了被版本控制的數(shù)據(jù), 用戶在本地操作數(shù)據(jù)的淺拷貝副本。

Subversion 發(fā)布后, 很快就顯現(xiàn)出它在版本控制領(lǐng)域的領(lǐng)導(dǎo)地位, 它的使用范圍越來越廣泛, 越來越多的舊版本控制系統(tǒng)被它取代, 即使是在今天, 它在版本控制領(lǐng)域也占據(jù)著重要地位。

優(yōu)勢：

• SVN支持空目錄
• SVN有更好的Windows平臺(tái)支持
• SVN可以check out/clone一個(gè)子樹(sub-tree)
• SVN支持特權(quán)訪問控制svn lock，在處理很難合并的文件時(shí)非常有用。
• SVN支持二進(jìn)制文件，更容易處理大文件(不需要把老版本拷來拷去)。
• 提交文件相對簡單，因?yàn)闆]有pull/push操作，本地修改通過svn update自動(dòng)的執(zhí)行了同步代碼的功能。
• 可以設(shè)置目錄級(jí)別的權(quán)限控制，你可以設(shè)置它只讀或者讀寫，而且非常適合大型項(xiàng)目。

B. Git

在 Subversion 開始出現(xiàn)的那一年, 一種新的版本控制策略—分布式的版本控制 (distributed version control)—開始受到越來越多的關(guān)注, 應(yīng)用也越來越廣泛。

Git是一個(gè)分布式版本控制軟件，最初由林納斯·托瓦茲創(chuàng)作，于2005年以GPL發(fā)布。最初目的是為更好地管理Linux內(nèi)核開發(fā)而設(shè)計(jì)。

Git具有以下特點(diǎn)：

• Git 中每個(gè)克隆(clone)的版本庫都是平等的�？梢詮娜魏我粋�(gè)版本庫的克隆來創(chuàng)建屬于自己的版本庫，同時(shí)你的版本庫也可以作為源提供給他人，只要你愿意。

• Git 的每一次提取操作，實(shí)際上都是一次對代碼倉庫的完整備份。

• 提交完全在本地完成，無須別人給你授權(quán)，你的版本庫你作主，并且提交總是會(huì)成功。

• Git 的提交不會(huì)被打斷，直到你的工作完全滿意了，PUSH給他人或者他人PULL你的版本庫，合并會(huì)發(fā)生在PULL和PUSH過程中，不能自動(dòng)解決的沖突會(huì)提示你手工完成。

Git 的缺點(diǎn)：

• Git 沒有嚴(yán)格的權(quán)限管理控制，一般通過系統(tǒng)設(shè)置文件讀寫權(quán)限的方式來做權(quán)限控制。
• 工作目錄只能是整個(gè)項(xiàng)目：比如 checkout，建分支，都是基于整個(gè)項(xiàng)目的。

C. SVN和Git

Git的優(yōu)勢就是SVN的弱勢，如果你不太關(guān)心代碼文檔權(quán)限控制，或者多人協(xié)助開發(fā)合并代碼，那么Git是你很好的選擇。

但是如果你需要控制代碼的安全，SVN的權(quán)限控制將能讓你放心代碼的安全性。而Git 無法提供細(xì)顆粒的權(quán)限控制。

一個(gè)非常好的問題。SVN仍然有很多用戶，因?yàn)槭褂煤唵�，更多的原因是用戶已�?jīng)習(xí)慣。

SVN出現(xiàn)較早，是很多程序員以及非技術(shù)人員學(xué)習(xí)使用的第一個(gè)版本管理工具。

GIT最早發(fā)布于2005年12月，起初用于Linux內(nèi)核開源項(xiàng)目的管理，由于GIT本身優(yōu)點(diǎn)眾多，使得工程師群體比較容易接受。

技術(shù)團(tuán)隊(duì)管理項(xiàng)目代碼，因?yàn)榉种л^多，并且有代碼review、合并等操作，推薦GIT；如果只是平常的文檔管理，比如非技術(shù)部門的單據(jù)、規(guī)章制度等，使用SVN和GIT都行，更多的是用戶喜好。

SVN和GIT各方面都比較類似，比如圖形界面工具操作簡單、命令行模式下常用命令非常類似、都可以和IDE集成。因?yàn)镚IT是較新的版本管理協(xié)議，所以支持更多的功能，比如Pull Request。

1，工具簡單易用

SVN和GIT都有非常簡單方便的工具，比如TortoiseSVN，Git GUI等工具。

2，基本命令

在基本的應(yīng)用場景中，SVN和GIT非常類似，比如拉取文件-修改-提交。

3，IDE集成

IDE開發(fā)工具和代碼管理服務(wù)集成，操作更高效方便。

4，分支管理

SVN分支是對文件的復(fù)制，所以比較占用磁盤空間，不如GIT靈活。

5，代碼合并Pull Request

團(tuán)隊(duì)協(xié)作時(shí)，GIT可以發(fā)起代碼合并請求，review完成后將代碼合并到正式分支，這也是開源項(xiàng)目最常用的代碼合并流程。

6，代碼托管云服務(wù)

主流云服務(wù)商都有提供免費(fèi)的代碼托管服務(wù)，并且支持私有庫，推薦使用，可省去繁瑣的配置、管理、備份維護(hù)等工作。

我是工作多年的Web應(yīng)用架構(gòu)師，陸續(xù)發(fā)布關(guān)于軟件開發(fā)方面的文章，歡迎關(guān)注我，了解更多IT專業(yè)知識(shí)。

樓主可以嘗試著把自己當(dāng)成一個(gè)項(xiàng)目管理者或者經(jīng)理來看待這個(gè)問題，而不是工程師或者程序員。

先說幾個(gè)假設(shè)，雖然不一定完全正確，但是應(yīng)該具有一定普適性：

• 工程師大概率是組里面技術(shù)能力最強(qiáng)最牛逼的
• 個(gè)體需要為團(tuán)隊(duì)奉獻(xiàn)/貢獻(xiàn)
• 工作習(xí)慣會(huì)影響個(gè)人習(xí)慣

我們再來看一個(gè)常見的團(tuán)隊(duì)組成：工程師，美工，策劃，PM。

美工和策劃可能是團(tuán)隊(duì)里面技術(shù)學(xué)習(xí)能力或者技術(shù)理解能力較弱的群體。因此，當(dāng)我們在決定項(xiàng)目管理方式的時(shí)候，要綜合考量團(tuán)隊(duì)人員的能力，而不是基于自己的喜好來選擇。這就像足球隊(duì)的教練一樣，把合適的人放在合適的體系以及位置上，不然球員踢起來怎么踢怎么變扭（對，我說的就是愛美麗手下的扎卡）。

言歸正傳，因此我們在選擇版本控制工具的時(shí)候也會(huì)有同樣的抉擇。在選擇的時(shí)候，由于美工策劃是相對的短板，我們可能需要考慮以下幾點(diǎn)：

• 策劃美工用起來方不方便，會(huì)不會(huì)增加額外工作量
• 工具的學(xué)習(xí)成本和曲線對于他們而言有多大多陡
• 他們犯錯(cuò)的幾率有多大的差異
• 犯錯(cuò)的成本有多大

下面模擬下正常工作中可能出現(xiàn)的場景：

1. 美工1創(chuàng)建了a,b,c三個(gè)文件，a已經(jīng)完成了可以發(fā)給工程師自己去玩了。

使用SVN：在文件夾窗口右鍵添加a，直接commit a就結(jié)了

使用Git：開一個(gè)本地branch 1，添加a，commit a，把develop branch更新到最新，合并branch1到develop branch，最后push。或者push branch1然后再去看一個(gè)pull request到develop。

2. 美工2看到美工1對a的改動(dòng)，想一探究竟。

使用SVN：直接update這個(gè)a就行

使用Git：git pull把整個(gè)develop或者branch1拉下來。

從上面對比可以看出來，git的使用對于美工策劃而言可能不是很直觀�？赡苄枰�他們費(fèi)一點(diǎn)腦子去理解這些操作。而且創(chuàng)建和更新某個(gè)文件夾或者文件可能是他們唯二會(huì)涉及到的操作，為此去理解git的工作方式對于他們而言可能負(fù)擔(dān)過重。畢竟文科生的思維方式和理科生不是很一樣所以有些問題的理解對于大多數(shù)工程師而言顯而易見，但是對于他們可能頗顯難度。

而且這個(gè)過程中，SVN的操作次數(shù)更少，通過UI的集成操作也更加直白減少了他們出錯(cuò)誤的機(jī)會(huì)。

當(dāng)然，以上只說到了從美工和策劃的角度來看待這個(gè)事情。但是如果從整個(gè)團(tuán)隊(duì)出發(fā)（我們說到的第二點(diǎn)假設(shè)是個(gè)人需要為團(tuán)隊(duì)奉獻(xiàn)），我們還得考慮團(tuán)隊(duì)的規(guī)模，團(tuán)隊(duì)的主觀能動(dòng)性等等因素。

比如一個(gè)小團(tuán)隊(duì)，2-3個(gè)開發(fā)，一兩個(gè)美工策劃，SVN應(yīng)該能得到很好的適配，不需要額外的學(xué)習(xí)能夠快速上手項(xiàng)目。雖然沒有分支管理，但是開發(fā)人數(shù)少，使用起來即使出現(xiàn)沖突，讓他們解決沖突也可能比讓美工策劃使用git的轉(zhuǎn)變來的容易。

但是如果考慮大一點(diǎn)的團(tuán)隊(duì)，15-20的開發(fā)，2-3個(gè)美工策劃，大家還分布在不同區(qū)域工作�；蛘邎F(tuán)隊(duì)成員里大家其實(shí)都愿意接受新事物新知識(shí)，這種時(shí)候使用git所帶來的協(xié)調(diào)性和管理優(yōu)勢遠(yuǎn)高于美工策劃所需要付出的學(xué)習(xí)成本，那么git將可能是一個(gè)更好的選擇。

最后，說一點(diǎn)，就像其他答案中說到的，存在即合理即有意義。很多技術(shù)沒有絕對的好和不好，git和SVN也是一樣，需要結(jié)合使用場景和團(tuán)隊(duì)情況才能做出最好的選擇。就像之前Spark和Hadoop，都說Spark牛逼，要取代Hadoop了，但是Hadoop依然在。有時(shí)候追求高大上并不是最好的，合適的才是最好的。常常開口閉口就是kafka，elastic search，流處理，但是到底應(yīng)該什么場景用才是最重要的。

個(gè)人淺見，希望對樓主有用。歡迎點(diǎn)贊收藏關(guān)注^_^

為什么一定要用git？絕大多數(shù)公司都是業(yè)務(wù)驅(qū)動(dòng)技術(shù)，業(yè)務(wù)上不需要，就不必要更新技術(shù)。svn或者git只是一個(gè)工具而已，重點(diǎn)是能否滿足公司版本管理的要求。

你說git好用，但它是分布式的，使用上肯定變得復(fù)雜了，因?yàn)楸镜匾粋�(gè)版本管理，server上還有一套。公司技術(shù)選型不只是考慮技術(shù)的先進(jìn)性，那太片面。還需要考慮成本，習(xí)慣，資源配置等等因素。

每種工具都有他存在的意義和用戶，git沒出現(xiàn)之前，svn不也是用了好多年嗎？

另外就是，技術(shù)選型的第一個(gè)要求就是滿足業(yè)務(wù)要求，不考慮其他其他因素直接用最先進(jìn)的工具和技術(shù)只會(huì)弄巧成拙。好比現(xiàn)在動(dòng)不動(dòng)就分布式，哪怕只有很少量的用戶和數(shù)據(jù)，大題小做，殺雞用了宰牛刀。

總之吧，根據(jù)實(shí)際需要選擇技術(shù)和工具，避免技術(shù)濫用亂用。技術(shù)先進(jìn)好用不是選型的決定性和唯一因素。

一個(gè)工具而已…這都要比較一下！java是世界上最牛逼的語言，是不是要打死我？

svn配置簡單，集中式管理，獲取、提交即可；git配置稍微復(fù)雜點(diǎn)，分布式管理，沒有一個(gè)集中統(tǒng)一的版本，命令獲取、提交、同步。前者適合文檔類管理，后者適合代碼開發(fā)類項(xiàng)目。

不要為了跟風(fēng)而使用git。如同后臺(tái)管理系統(tǒng)總覺得不適合前后端分離，跟風(fēng)做前后端分離才是可怕，成本，交付周期，效率，運(yùn)維等問題，還是傳統(tǒng)組件化適合后臺(tái)管理系統(tǒng)。

企業(yè)用svn的多，個(gè)人開發(fā)者git的比較多，看場合

首先要問問你自己為什么感覺用git就有點(diǎn)高級(jí)的這種認(rèn)知。svn，git僅僅是工具。并不能大量提升你的工作效率。我覺得可能有幾點(diǎn)

1.很多公司之前的習(xí)慣，svn已經(jīng)部署好，里面有公司大量的項(xiàng)目，不太好轉(zhuǎn)換

2 很多人不太會(huì)使用git ，覺得svn已經(jīng)夠用了。當(dāng)然選擇自己熟悉的更方便出現(xiàn)問題好解決

3 頭部效應(yīng) 就是領(lǐng)導(dǎo)決定使用啥。

其實(shí)我個(gè)人認(rèn)為項(xiàng)目管理工具，應(yīng)該是適合這個(gè)團(tuán)隊(duì)的就是最好的。沒有什么對錯(cuò)之分，svn也還行，雖然git有點(diǎn)那么點(diǎn)小優(yōu)勢。