使用svn分支

大學期間我第一次作項目的時候，當時的三我的分別作不一樣的功能，互不影響。過了一個寒假，你們約好到一個地方把代碼整合到一塊兒。那時你們都沒有版本控制的概念，通過了一下午的整合，總算是把項目可以完整成功地運行起來了，後來那個項目也一直沒有用到版本控制。個人兩個同窗比我機智，他們合做一塊兒作畢業設計，一個前端，一個後端。虧他們想得出拿雲盤來進行協做，開發完的代碼就上傳到雲盤，另外一半則同步一下雲盤，真讓我啼笑皆非。

 

後來，我接觸過大部分項目都用的是svn來進行版本控制，不知你們跟我同樣是否只是用svn來備份代碼或協做。是的，在svn的使用中，大部分人都只用到了其中的trunk，你們都在trunk上面修改提交協做。人少項目小時還勉強沒什麼問題。一旦項目大了人多了，問題也就慢慢地浮現出來。

 

項目大了，當你正在trunk上開發一個新功能的時候，忽然被告知要修復一個緊急bug，這時怎麼辦？bug若是不涉及到如今開發功能的文件還好，改完bug的文件直接上線便可。可是若是涉及到正在開發的文件，那麼你只能先默默地註釋掉新功能的代碼，代碼若是多且分佈廣的話真的會吐血。

 

參與項目的人數多了，都在trunk上開發，今天我開發的功能要上線，但是其餘的同事提交了開發一半的代碼，代碼混在一塊兒就很難放心地上線了。同事之間天天的不斷代碼提交會增長項目的不穩定性，沒有人會在項目不穩定的時候就把它放到線上給用戶使用，這不是給本身挖坑嗎。可是，我真的經歷過，想起那時也真是愉快的時光。那時趕着項目上線，而且沒有測試，一聲令下就上線。用戶就是咱們的測試，天天都有許多的用戶打電話過來反饋這裏有問題那裏有問題，不過這段時光總算是過去了。

 

以上羅列的種種問題就是爲了接下來作鋪墊。分支能夠解決以上等大部分問題，那麼，分支又是什麼？建立一條新的分支能夠理解爲把代碼再複製一份，在新分支上面的改動不影響原來代碼的運行。而且該分支上的代碼，也就是複製的那一份的代碼也會被添加到版本庫中被管理，還能夠進行分支合併的操做將代碼們進行合併。好比，你被指派去開發一個功能，這個功能可能得花上一段時間的開發，爲了避免影響其餘同事在原來功能上的開發，你能夠拉去一條新的分支進行功能的開發，功能開發完畢即可以合併到原來的主幹上。

 

大部分用svn進行版本控制的開發者都不多甚至不用svn的分支，有的人說不必，有的人說不會，有的人說合並很麻煩有不少的衝突，這些都是藉口。在稍微有點規模的項目中，只有一條主幹的trunk是沒法保證項目的穩定性，至少得保證trunk主幹上的代碼是穩定的。svn建立一條分支是在遠程機器上建立的，建立完畢你須要checkout到你本地才能使用。svn的一切操做都是以遠程機器爲主，你想進行分支合併的操做時得先將本地的代碼提交併更新後才能進行合併操做，最後合併了其餘分支上的代碼後還需進行提交。

 

那麼，分支得建立多少，該怎麼使用。參考了這篇「多分支開發策略」的文章，目前項目中我有四條一直保存着的分支。master主幹分支也就是trunk是默認存在的，而後我從trunk上檢出了三條分支，分別是hotfix、dev、release。hotfix分支是專門用來應對緊急bug的修復，dev分支是用來新功能的開發，release分支是用來發布測試版本，master則是用來發布正式版本。dev上開發完畢能夠合併到release上，而後能夠繼續功能的開發。一旦release被測出有bug，能夠直接在release上面進行修復。線上的bug則可使用hotfix分支進行修復。

 

理論方法說得差很少了，接下來就是實戰了，知道了那麼多，但仍是沒有具體的操做也是白搭。能夠戳這個「TortoiseSVN中Branching和Merging實踐」學習如何操做svn分支的合併。須要注意的是，兩條分支之間的合併都須要把本地的代碼進行提交併更新才能進行merge操做，不然，你本身試了就會知道了嘿嘿嘿。