如何讓公司從 SVN 改到 Git？
以前我是用git，其實我沒有用到git的什麼高級用法，svn與git的區別我看過很多遍，但是我其實不明白都說了些什麼，只是覺得git肯定比svn有優勢。新公司使用的是svn，雖然我們的開發都是小活，svn應該完全夠了，不過對於我使用過git後，還是希望公司能改到git管理，或者慢慢過渡到git管理，這個應該如何去改變公司？
請以解決問題為核心，不要為了用技術而用技術。
其實第一次聽說要改用 git 進行版本控制我是拒絕的，因為，你不能讓我改用 git ，我就馬上去改，第一，我要用一下，因為我不願意只稍微試了一下，就加上一些明明不懂，非要裝逼說好的說辭，然後吹鼓 git 有多叼，合併代碼時 「咣」 一下， 衝突就不見了，這樣我的同事一定會罵我，根本沒有這樣的版本管理器，就證明這個 git 是假的。後來我也經過證實它確實有自己的優勢，比如本地管理，分散式等等，我用了大概一個月左右，也用了一些高級用法，感覺還不錯，後來我在給別人宣傳的時候，也不瞎比吹牛逼說 git 有多叼，因為我要讓我的同事看到，我用完之後，代碼管理變得簡單輕鬆，你們用完也會變得輕鬆。
「svn與git的區別我看過很多遍，但是我其實不明白都說了些什麼，只是覺得git肯定比svn有優勢」
你自己都不知道有什麼好處，憑什麼讓其它人跟你走如果你覺得某樣技術「好」，"Just show them why, in action, rather than in concept."。在我呆過的兩個團隊裡面，一個用cvs，一個用mercurial，我都推用git，後來每個人都覺得非常好用。當然，因為項目是我負責的，推起來比較容易。但有一點要記住：你必須能夠解決他們所遇到的任何問題。
看你是什麼角色！
如果你是技術老大，而且確認能用好 git ，就可以推。畢竟好處多多。
否則，很難！
git 有一定的使用門檻，對不夠 geek 的員工接受有一定的困難。
有空了我來補充在我們公司推行的曲折史。
---------------------- 應評論要求，補充內容的分割線
我們是創業公司。因為我之前工作中用過 git，感覺到他的強大、方便，所以一開始我就力推 git 。
但是，對於大多數之前未接觸過 git 的員工來說，用 git 還真是有些難為：有一個同事曾經錯誤地使用命令，多次丟失代碼。
即使：組織過培訓、遇到問題時分析，但還是有人怕這個。
我總結下原因：
1）學習曲線 ：git 學習曲線的確有點陡峭：命令有點多、狀態有點多。尤其是還有中間狀態。
2）英文：不少人對英文是 - 忽略。git 其實每一個操作，都有提示，尤其是狀態需要關注時。但是，很多同事不太看這個，悶著頭教科書式敲命令。
3）學習新東西的態度與能力。這個就不展開說了。
大概半年後，有同事做到這樣了：每做一個比較大的變更時，把整個本地 git 庫目錄整個備份一下。後來，那個組在大多數員工的要求下，改回了 SVN。
還有另外一半同事在堅持使用 git 。但是，還是偶爾有使用過程中的問題要問問，發生提交問題。為此，我們又做了一次培訓，並且做了一次考試。
至現在，大部分人也還只是基本地使用。高級一點的用法也還少。
----------------------
樓主的另外一個問題是：簡單用時，未搞明白 git 相比 SVN 到底好處在哪裡。
建議看看這篇文章：對 git 維護者濱野純的訪談 - 關於濱野純的訪談
我的看法是：
1）merge
2）branch
3）本地庫，等其他細節
即使項目小，如果大家的學習能力與態度到位的話，也建議使用 git 。
嗯，特別提示下，上句話里的 「如果」。
首先，同意 "請以解決問題為核心，不要為了用技術而用技術。"
其次，這個轉換我覺得應該由底向上推，最好不過了，廣大工程師認識到可以通過使用 git 提升工作效率，減少重複工作，更加方便的溝通。git 的切換也會導致上線系統的修改工作，其實切換最重的應該是上線部署系統。當然如果沒有收益，也沒必要一定使用 git，svn 也是沒有問題的。
最後，如果說轉到 git 有什麼優勢的話，我想說的是方便切換上下文，以及代碼間的協作。
代碼衝突，突然來臨的修改任務，代碼 review 這些其實都是工程師經常面臨的問題。git 在這些方面處理的還是不錯的。git 默認的 stash, chekcout, branch, 都提供了一些常用的切換上下文的便利。在一個混亂沒有章法的代碼管理的情況下，git 這樣做，約定了一些使用習慣，實際上是提升了工作效率。
用SVN：
對於一個辦公室內的協作是：
「我提交了啊，你更新下」
「好」
對於跨辦公室的協作：
「我靠，誰又把我代碼覆蓋了？」
感覺知乎上一些用戶，完全答非所問，你想挑刺回家挑行不？
沒用過兩者的，沒有學習過兩者的，就別在瞎回答了。
git svn完全是兩種概念，只要你能明白分散式和集中管理，你就能明白，你的公司應該用什麼。
git 適合開源項目，各人都有一份完整的拷貝，你一個公司要那麼細的歷史細節幹什麼？
svn集中管理，所有代碼維護在中心。你一公司肯定得有個主幹線路，集中式的管理。
不要盲目的跟風，git快，git好，那不是一樣的。
假如一個web項目，伺服器在遠程，每個人做完修改就可以立即同步，肯定是svn最快最省。
用git ,你的遠程pull是非常麻煩的。你得多操作好多項，能才pull，而用svn一個commit搞定。
所有人都受益……
很多人根本不動腦子, 只知道水波逐流.
在做出大的影響的決定前, 需要仔細權衡, 而不是拍腦袋.
1. 實際使用中SVN是否已經足夠, 而GIT取代SVN能帶來哪些變化, 這些變化能否對團隊協作產生積極的推動?
2. 代碼管理系統和團隊中的每個人都息息相關, 你想做出更換, 團隊內的其他成員是否能夠接受? 他們願不願意去學習新的管理方式和理念?
3. 公司是否支持切換到GIT?
我非常贊同排名第一的童鞋, 不要為了用技術而用技術.
然後我再加一句: 在工作中, 不要為了折騰而折騰.
你想折騰, 自己搞個開源項目自己玩唄.
如果我去說服公司從svn轉git，會使用下面的例子
1.公司停電後，svn就不能使用某些操作，而git可以
2.某些同事忘記提交某些代碼，導致我更新後程序無法運行
不用改變，自己用git做svn客戶端就行了
對於開發者來說，需要自身對於軟體開發有著強烈的興趣和品質要求，那麼在了解到 Git 以後，會很自然的開始使用它，並且愛上它。
對於大多數的普通開發者，他們對於版本控制的理解僅到"一個有 Undo 功能的代碼存儲"，對他們來說，使用 VSS、TFS、SVN 以至 HG, Git 是沒有任何區別的，我見過太多把 Git 當作 SVN 用的程序員。
Git 的學習曲線過於陡峭，但是作為一個程序員，你在真正了解熟悉到它以後，你會覺得這就是你需要的工具，那時候你恐怕會巴不得把自己所有東西都用 Git 管理起來。
因為我就是這樣一個 Git 深度中毒用戶，包括自己的工具及開發環境，全部都使用 Git 在管理，在切換到另一台電腦時，我只需要 clone 一下我的環境，運行初始化腳本，即可開始工作。
git svn rebase
git svn dcommit
用git， 管理精細化，品質卓越化。
用git， 提交小步化，回歸快速化。
用git， 非同步工作化，工作生活化。
在公司里還是SVN更方便。你們說的git那些個好處，對於公司里開發商業軟體來說，用得到嗎？
還有前面有人拿branch來說事，真要把我笑噴了。人家SVN的branch、merge機制也很完善好不好。
連SVN都用不好的人，你指望他用好git？笑話。
如果是你自己的小項目，你愛用啥就用啥，儘管拿出你的Geek范兒，沒問題。但如果是在公司里，可不一定人人都是Geek！
怎麼，你看那些不是 Geek的人不爽嗎？你有本事，你把這些人的活兒都幹了？
要麼你是部門老大，你把Geek都留下，把非Geek都開了。
否則，你還是老老實實接受現實。我覺得SVN是非常折衷的一個版本控制工具。不一定是最好的，但卻是各類人都能好好地用起來的一個工具。
以前在網易有道，推廣git都異常困難，可以想像普通公司有多難了。
簡單的向公司說明兩點好處應該就夠了。
1.有完善的版本管理機制（不管是集中式還是分散式），不怕版本管理伺服器出故障。
2.能夠更快速的響應市場需求變化，提高工程師效率和合作質量。
大部分人只會選擇會的 而不會選擇好的
如果是一群沒有上進人 他們是不會考慮熟優熟劣的 他們不會考慮如何提高生產力的
就是一版本控制系統！還折騰！看需求吧，你是寫代碼還是玩版本控制器了
剛好在個人的努力下，讓公司從vss遷移到git，一步到位。首先，公司用vss有一些問題，特別是vss不能跨平台，現在iOS開發就不能集成。第二，老闆想用svn，因為熟悉，在老闆決定用svn之前，我搞了一個會議，把git吹上天。第三，把其他同事拉進來，他們有什麼疑問，立馬過去回答，他們覺得好用了，老闆也就樂意用了。
推薦閱讀：
※Git 相比 svn 和其他版本管理工具的核心優勢有哪些？
TAG:公司 | 版本控制系統 | Git | SVNSubversion |