前言
查找了SVN的相關知識無論是園子里還是百度都只有一些理論,而有實踐教程的都是點到為止,並沒有一個完整的關於團隊如何使用SVN協同工作的教程,因此寫下該篇希望能對大家起到一點幫助。
面向人群
本教程面向有一定svn基礎的,而且之前都是單人開發,對團隊開發如何使用SVN並不了解,但急需了解的的同學。
背景
由於團隊開發是如果沒有正確的使用SVN經常出現A在做一個需求涉及到a,b項目,而B再做另一個項目涉及到a,c項目。
然后A做完了直接提交了代碼,但是並未經過測試。B的代碼測試完畢然后提交准備投產,然后發現A已經提交了代碼,所以他就獲取了A的代碼,編譯后如果不詢問A是否代碼經過測試,可能直接投產了,然后投產出現了問題。或者知道了A的代碼還未測試,必須等測試通過后才能投產。否則只能恢復到測試完的代碼進行投產。最后甚至有可能就忘記提交了。
解決方案
規定代碼必須經過測試后才能提交,這一定程度上解決了這個問題,但是這就偏離了版本控制的初衷而且每次開發代碼必須一次性開發完成,若開發中途發現問題,導致一部分代碼需要重打,那么就不能很好的回滾。
團隊開發生命周期
創建新項目
以下操作都是使用VS的VisualSVN插件,其他插件使用方法都是差不多的,在文件資源管理器中使用方法原理是一樣的。
首先針對我們的SVNTest1項目

-
在項目右擊菜單中將整個項目加入到SVN中

-
首選選擇需要加入的根目錄點擊下一步

-
新項目選擇新建倉庫,若已經在SVN服務器創建目錄接口就選擇添加存在項目

-
選擇SVN的路徑

在svn中我們創建的倉庫下包含trunk,branches和tags三個文件夾,trunk為主線,branches為分支而tags則是標簽
trunk:用於存放主線代碼,我們不能在這里進行開發
branches:用於並行開發使用,每個需求或者bug修復都需要創建一個分支
tags:這里的代碼不能編輯,只可讀取,每隔標志性版本我們可以在tags中創建一個標簽,如V1.0正式版,那么當代碼合並到trunk后可以創建一個標簽,如果接下來開發v2.0版本,而突然發現v1.0有個bug,就可以將次代碼創建一個新分支用於修復bug,修復完成后可以合並到主線任務中並創建v1.1標簽
我們可以使用2種結構開發我們的項目,第一種是每個項目文件夾下創建這三個目錄,然后進行開發;第二種方式在根目錄下就創建三個文件夾,然后在這三個文件夾下有多個項目。這里我用第一種方式,兩種方式只是結構不同,原理一樣的 -
如果需要驗證輸入用戶名和密碼,然后點擊導入,新項目就導入成功



-
導入成功只是在我們本地SVN緩存中導入成功,我們必須提交到服務器中



-
我們可以將bin和obj這些目錄忽略掉,否則每次編譯提交后他人更新都會有沖突,在VisualSVN插件提交默認已經忽略了這兩個目錄因此直接提交即可。




創建分支
現在主線已經創建好了 ,如果我們要進行開發或者修復bug,請不要在主線上面開發,我們必須先創建分支,然后再分支上進行開發,這樣就不會影響到主線的代碼,當分支開發完成並測試通過后可以合並到主線,同時若分支沒用即可刪除。

在工具欄中有常用的按鈕,方便我們使用,如果使用其他SVN插件也是類似的,我們也可以直接在項目右擊進行操作

不知為何在菜單中沒有創建分支選項,我們直接在工具欄中創建,在文件夾右擊創建分支也是一樣的


如果否選切換工作副本至新分支,那么創建完會自動切換,如果沒有鈎,那么我們還是在原來的主線,我們暫時不勾選手動切換分支

創建完成由於我們沒有勾選自動切換,svn就提示了我們手動切換,同時SVN服務器中也有了新的分支

切換分支

默認只有主線,這里我們選擇切換到其他分支



現在我們已經切換到新的v0.1的分支了,現在假設person2同學需要對對該項目進行同步開發,因此我們希望每個人能區分開來,我們可以將項目根據人來區分,如
/Test/branches/person1/v0.1,/Test/branches/person1/v0.1-bug1,/Test/branches/person2/v0.1等,也可以根據項目來區分,如如/Test/branches/v0.1/person1/xxx,/Test/branches/v0.1/person1/fix-bug1,/Test/branches/v0.1/person2`等。只要決定一個規范既可。
-
現在我們約定以
/Test/branches/v0.1/person1的方式來存放,那么首先person1可以創建一個新的分支進行開發。
-
模擬person2同學並行開發,由於B同學需要獲取全新的項目,因此需要首先從版本庫中獲取該項目



現在B同學需要創建一個新的分支到person2目錄

此時目錄結構如圖所示,為了避免干擾項,我已從svn服務器刪除了第一個創建的分支

-
現在person1和person2可以獨立進行開發並提交代碼到自己的分支上而不會影響主線,更不會影響其他人的開發了
-
person1添加了一個文件1.cs



-
person2添加了一個文件2.cs



我們發現他們可以正常提交而無需更新,因為實際他們是在不同的分支工作,當然不會產生影響
-
合並代碼
假設person1已經開發完成並通過測試需要將分支合並到主線
-
切換到主線

-
點擊合並




到此為止已經將分支合並到我們的主線,但是這里的主線只是我們本地的主線(svn會將分支保存到不同的目錄,因此我們本地不同分支會存放在不同的臨時目錄的,在svn文件夾下,不要手動去修改該目錄)

-
將本地主線提交到服務器

我們可以看到合並到主線后,我們的解決方案管理器有些黃色的圓點代表修改,我們看下svn服務器

發現我們雖然提交了代碼實際服務器主線還並沒有1.cs文件



提交成功后發現svn服務器主線已經有該文件
4. person2已經開發完成並通過測試需要將分支合並到主線5. person2需要切換到主線
6. 切換完點擊合並



會發先有沖突,因為person1已經提交了代碼,而你本地的代碼並不是最新代碼,所以合並之前先將主線代碼合並到分支,然后分支解決沖突后提交到服務器分支。再重新切換到主線進行分支合並,此時完整的流程即走完
-
以上3個步驟忽略,不要直接切換主線,而是提交代碼前先保證分支代碼最新,首先將主線合並到分支



-
解決沖突后,即可提交代碼

代碼還未提交時SVN服務器person2目錄實際還沒有1.cs文件

提交代碼后就有了

-
合並分支到主線




-
提交主線代碼

由於person1並未獲取person2的代碼因此person1實際只有1.cs,而person2由於在person1提交的代碼后更新了主線代碼,因此perosn2有1.cs和2.cs
正式版本發布
版本發布只針對trunk的目錄進行發布
現在開發任務已經完成,我們認為這個版本已經很成熟,我們希望把這個版本定為v1.0,我們現在可以刪除分支,同時將該版本打個標記
-
刪除分支
直接刪除無用分支即可

-
做v1.0的標記
標記其實就是一個分支,只不過tags文件夾應該設置為只讀權限

切換到主線切出一個tags


bug修復
現在我們可能在開發2.*的版本了,突然發現1.0的版本有bug
-
從tags/v1.0版本中切除一個分支修復bug


-
修復bug后做一個v1.1的tags,或者根據情況合並當trunk


-
修復bug后合並到trunk分支



結束語
至此整個團隊開發生命周期就講解完畢,接下來就是不斷佚代的過程。
以上是我個人理解,如果看來此篇文章略有所學,請支持下,如若有誤煩請指正。
PS: 第一次用vs code編寫,還是挺好用的(●ˇ∀ˇ●)

微信掃一掃二維碼關注訂閱號傑哥技術分享
本文地址:https://www.cnblogs.com/Jack-Blog/p/5426956.html
作者博客:傑哥很忙
歡迎轉載,請在明顯位置給出出處及鏈接)

