對CVS,SVN等軟體版本管理中Tag，branch,merge的一點理解

對於項目開發過程中，會出現以下的一些情況：
（1）對於某個項目開發了一定的階段，決定發布一個初始版本V1.0；
（2）V1.0版本上線，對於該項目繼續開發（可能增加新的特性、功能更新等升級至V2.0），此時對於原先的代碼已經進行了改動；
（3）此時在V1.0中發現了一個BUG，需要馬上改動，或者需要在V1.0中緊急加入一個特性，需要對於原始碼進行修改了。
沒有版本控制，這個時候麻煩來了。考慮一個原始方式（自己上學的時候就這麼幹過）：
（1）開始對於V1.0版本項目拷貝一個檔案夾，作為備份；
（2）對於新的版本開始在V1.0上面開發，這個時候代碼或許已經變動很大了；
（3）需要對於V1.0進行修改，則對於原先V1.0備份代碼再拷貝一個目錄，修改其中BUG，進行加入一個特性；
（4）當對於V1.0的代碼修改完成後，轉向開發中的V2.0版本，此時，如果將兩邊的代碼進行統一合并，即：對於V1.0的BUG、緊急特性也同時更改到V2.0中；
（5）Ctrl+C、Ctrl+V，刪減代碼，呵呵。。。混沌了。。。。。基本上確定無疑的會導致代碼不一致。

 

採用CVS、SVN等，可以管理了：
（1）對於V1.0開發完成，進行上線了。此時對於該版本使用“TAG”標記-V1.0_Release，"Tag“為代碼某個時間點的快照（不能夠在快照上面進行修改）；
（2）繼續進行V2.0代碼的開發；
（3）需要修改原先的V1.0代碼了，此時通過TAG標記擷取當時的代碼快照（如果此時直接進行修改，然後commit提交會報錯，不能直接在TAG版本上面進行修改）；
（4）基於該Tag版本，建立Branch程式分支，作為V1.0_Release_r1；
（5）在V1.0_Release_r1分支上修改BUG，增加緊急特性；
（6）在原先的V2.0代碼中並行進行開發，此時兩邊可以同時進行；
（7）V1.0_Release_r1對於BUG等處理完成之後，發布，作為V1.1上線；
（8）此時原先在V1.0_Release_r1修改的BUG,在V2.0中，仍然存在，再進行”Merge“，增加到V2.0中；
（9）OK。一切都結束了。

 

隨便寫寫。呵呵