我呆過的公司，要麼是git，要麼是svn來做程式碼版本管理工具，不過在我看來SVN用的還是比較多的。

說實在的，git我也不會用，雖然道理差不多。

今天來講一講SVN吧。

抱歉，也沒有去深挖、去追根究底這是怎麼來，又是怎麼發展的，我是個

實用主義

，我只告訴你這個工具一般使用方法。

瞭解就行。

能用就行。

一、SVN是個什麼東西？

其實吧，你可以這麼理解：

在一個專案開發中，不是一個人在提交程式碼或檔案，而是很多人，有前端、後端、策劃、測試，關鍵每個崗位都不是一個人，而是多個人。

怎麼讓這麼多人配合起來？

專案就只有一個專案，如果是一個人，那好，直接在自己本地把程式碼一改。

完美。

那兩個人呢？

還是同樣的專案，你電腦存一份，我電腦也存一份，等我們兩個都修改好了。

再把改動的都同步一下。

雖然有點麻煩，但還是OK的。

那三個人呢？

五個人呢？

十個人呢？

二十個人呢？

一樣的方法，那還不得爆炸。

這樣的專案還不如一個人搞呢。

太麻煩了。

同樣效率也低。

所以就出了類似於中央處理器一樣的程式碼工具，比如svn。

svn的作用是什麼？

就是為了解決多人合作的。

如果你看了我前面寫的主幹與分支的概念，那麼你就可以這麼理解。

svn作為一個伺服器，當然也是一個單獨的電腦。

其實它就是這個專案的主幹。

一個人的話，還是老樣子，自己改就行。

兩個人的話，就可以從svn這臺伺服器的專案程式碼全部複製到自己的電腦本地，就是一個分支。

三個人也是一樣，更多的人，也是這樣。

都是從svn裡把完整的專案copy一份出來，放到自己的本地電腦，可以想象為一個分支。

分散是分散了，還不是跟之前一樣嘛，不就是多了一臺SVN的伺服器？還多用了一臺電腦呢。

多人合作的關鍵就在於合併。

說到合併，就需要說到提交：你在你自己本地改了的內容只對你生效，其他人不會生效。

為了生效。

如果你這麼一個人一個人去傳遞你的改動，那就太麻煩了。

有了SVN，你只需要把修改的程式碼傳到svn，對於那些需要你改動程式碼部分的人而言，就直接從svn拉取就ok了。

所以流程就沒必要從你直接單獨傳給ABCD，或者你傳給A，再由他們互相傳，直至所有都更新到。

突然 有點像小時候傳作弊答案一樣。。。

svn它像一個完整的中間商，但是它不賺差價。

不僅不賺差價，而且衝突了還不會給你上傳。

那什麼是衝突呢？

比如svn有一份檔案1，第一行是四個字：

提交衝突

。

同事A把這份檔案複製到他的電腦，並且在第一行的位置加了兩個字，變成：提交衝突了嗎。

同事B也把這份檔案複製到他的電腦，然後在第一行的位置減了兩個字，變成：提交。

如果是同事A先把這份檔案提交到了SVN，那麼這份檔案1的第一行就變成了：提交衝突了嗎。

這時同事B也提交，SVN一看：你這怎麼提交的還是老版本？

不行，不給你提交，直接給你個報錯：conflict（衝突）。

那同事B也想提交怎麼辦？

那他首先需要把這份檔案更新到最新版本，也就是說，把第一行的“提交衝突”，先更新成“提交衝突了嗎？”

更新完之後，再刪掉“衝突了嗎。”，只剩下“提交。”

這時再上傳，svn就沒道理拒絕了。

現在svn就從最初的“提交衝突”，變成“提交衝突了嗎。”，再到現在的“提交。”

完成了整個版本的更新管理。。

說白了，它就是一個提交和拉程式碼的工具。

應該明白了吧。

不明白就再看一遍。

再看一遍還不明白，

那就算了。

接著往下看吧。

讓我想想，對於我們測試而言，能拿svn做 什麼。。。

算了，我直接擼一遍完整的流程吧。

假設你現在入職了一家新公司，這是你上班的第一天。

你的leader讓你先down一份自己專案的程式碼，於是給了你一份svn的安裝包，和一個svn地址的url。

然後就讓你自由活動了。

你傻瓜式的下一步下一步把svn安裝成功了。

然後你問leader：接下來怎麼辦？

leader：你先在e盤新建一個資料夾

你不會傻傻地在C盤建立一個吧？

於是你在e盤建立了一個資料夾：新專案

leader：你最好改一下名字，不要用中文，不然會出現一堆亂七八糟的問題，我建議你把資料夾名字改成英文縮寫+時間的形式。比如NEW0908。

你聽著有道理，於是把資料夾改成了NEW0909，改完後接著問leader然後怎麼做？

leader：你先把

專案程式碼

都拉到本地。

你先點選滑鼠右鍵，看到上面的checkout了嗎？點這個。（checkout，檢出）

然後你再把我剛剛給你的

url地址

貼上上去，再點OK。

你按著leader的指示，複製完url，然後點選OK，你看到一堆的update刷得你眼花繚亂。

你邊玩手機，邊看著下載進度，一小時後，你終於點選了被從灰色到高亮的ok按鈕。

然後你繼續問leader接下來怎麼辦。

leader：你先把專案用unity開啟。

然後就到了第二天。

你發現了人生第一個bug，很開心。

開發大佬跟你發了訊息說，這個bug已經修復了。

你讚歎於開發大佬解bug的速度是如此之快，然後開啟unity再去看下，結果bug還在。

你心情有點複雜：開發大佬都說解決了，為什麼我這裡看這個bug還存在呢？

想不通就問leader。

leader：你程式碼是不是沒更新？你更新完再看。

你默默地點了一下update，又發現一堆的程式碼在載入。

恍然大悟：哦，原來需要先更新啊。

你更新完再開啟unity，結果發現這個bug還在，你再次詢問leader。

leader拿起你的滑鼠，點選showlog，檢視一下專案提交日誌。

leader：看上傳記錄，都沒提交。

你只能硬著頭皮問開發大佬：大佬，這個是不是沒提交啊？

開發大佬過了一會兒給你回了一條資訊：抱歉，剛剛漏傳了。

你發了個可愛的表情。

然後繼續update，再開啟unity，結果發現這個bug還在。

你再次問開發大佬：我剛更新了，bug還沒解決。

開發大佬秒回了你的資訊：不可能啊，我本地是正常的啊，是不是程式碼衝突了？

你只能再求助leader：剛剛開發已經提交程式碼了，但是我更新完還是老樣子。

leader：程式碼衝突？那你還原一下。

你點選了revert（還原），接著是一段程式碼載入，再次開啟unity，結果發現bug還在。

你撓了撓頭，一臉懵逼地再次 問leader。

leader：還原不行，那你再清理一下。

於是你點選了cleanup（清理），照樣一頓程式碼載入閃爍。

你再次開啟unity，結果發現bug還在。

leader：那肯定是bug沒改好。

開發大佬再次給你回了個資訊：剛剛打錯了一個字元，你更新再測一下。

你再次點選update，看unity終於bug解決了。

你開心地像個300斤的胖子。

第二天就這麼愉快地結束了。

第三天你照常更新之後，發現昨天這個bug明明已經解決了，怎麼現在又出現了。

你問出了你的疑惑。

leader：你回退一下版本看看。

你點選showlog，翻到昨天的版本，點選了revert to this revision（回退到這個版本）

又是一陣眼花繚亂的載入，你開啟unity，發現bug是解決了的狀態。

你向開發反饋了這個情況。

開發大佬過了一會兒給你回信息了：xxx把我的程式碼給覆蓋了，你再更新看一下。

你嘗試更新之後，bug是解決了。

就這麼開心地度過了第三天。

第四天的時候，leader讓你寫一份專案體驗報告提交到svn測試專案。

於是你用了一天的時間，終於在下班前選擇了commit（提交）。。。