SVN衔沼，一個版本控制系統(tǒng)，用于團(tuán)隊(duì)協(xié)作開發(fā)责静。
版本控制：
標(biāo)記不同的版本需要使用編號墨缘，SVN使用Revision來作為版本編號星虹。
Revision是一個隨著提交遞增且唯一的自然數(shù)，每次新的提交Revision都會加一镊讼。
Revision應(yīng)用于整個倉庫宽涌，不只在單個文件上生效。（修改了倉庫中一個文件蝶棋，提交之后其實(shí)整個倉庫Revision都增加了卸亮，每個Revision可以理解為整個倉庫在某次提交之后的快照。）
協(xié)作：
協(xié)作開發(fā)需要關(guān)注問題就是多人修改同一個文件時如何保證修改正確的合并起來玩裙。File Sharing和Lock-Modify-Unlock模式都有各自的缺陷兼贸，SVN使用的Copy-Modify-Merge模式很好的解決了這個問題段直，如下是對三種模式的介紹。
File Sharing寝受，會有操作覆蓋的問題坷牛。
Lock-Modify-Unlock罕偎，同時只能有一個人在讀寫很澄，影響協(xié)作效率。
Copy-Modify-Merge颜及，SVN采用的模式甩苛，不會有覆蓋的問題，且不影響相互的工作進(jìn)度俏站。
版本管理
SVN常用于代碼版本管理讯蒲，常用的版本管理模型分為兩種。
主線開發(fā)模型：
- 在trunk上進(jìn)行版本開發(fā)
- 版本完成開發(fā)并測試通過肄扎，準(zhǔn)備發(fā)布墨林，從trunk copy 一個release分支出來進(jìn)行發(fā)布。
- 新版本繼續(xù)在trunk上進(jìn)行開發(fā)犯祠，重復(fù)步驟1和2
- 如果有一些特殊的功能模塊需要獨(dú)立開發(fā)（比如可能無法和版本一起上線）旭等，從trunk上copy Feature Branch進(jìn)行開發(fā)，完成開發(fā)后merge 回 trunk 進(jìn)行發(fā)布衡载。
使用場景：維護(hù)人員較少搔耕，定期發(fā)布，團(tuán)隊(duì)成員一般都是一起做一個版本的功能痰娱，且同時發(fā)布弃榨。
release主線，功能分支開發(fā)模型
- 主線為release版本梨睁，用作發(fā)布
- 有新版本或新功能鲸睛，從release中copy一個feature branch來，進(jìn)行開發(fā)坡贺，開發(fā)完成之后merge 回release分支進(jìn)行發(fā)布官辈。
使用場景：維護(hù)人員多，發(fā)布頻繁拴念，無固定發(fā)布周期钧萍，多功能分支。
合并
上述兩種方案都涉及到兩種合并：
- feature merge 回主線政鼠。
- feature 定期和主線代碼同步风瘦，將主線代碼merge到feature中。
- SVN建議盡量避免該種情況公般，因?yàn)閙erge起來沖突會比較多万搔。實(shí)在有必要胡桨，建議只定期merge有價值的改動
- 完成同步操作，將主線merge到feature上和從主線copy一個分支將feature merge上去瞬雹，兩種做法本質(zhì)上沒有區(qū)別昧谊，后者并不會避免沖突的發(fā)生，同時后者還多操作酗捌。
沖突：
因?yàn)槭菂f(xié)作開發(fā)呢诬，所以會有各種分支，在分支合并時肯定會有沖突胖缤，SVN中將沖突分為兩種尚镰。
- text conflicts：兩個人同時修改了相同文件，且修改無法很清楚的merge（修改了同一行哪廓，但是修改不同）狗唉，會報該問題。
- tree conflicts：目錄層面的conflicts涡真。本地修改了一個別人刪除的文件分俯，在更新merge時會報該問題。其他可以歸為目錄conflicts的操作都會報該問題哆料。
特殊情況舉例
除了上述提到的缸剪，feature可能需要和主分支保持定期同步，同時還可能需要和別的feature保持同步剧劝，我們在以release為主線的情況下舉例該情況橄登，并支持一些錯誤的操作方案以及正確的操作方案，有助于加深對Revision和conflicts的理解讥此。
場景
- release作為穩(wěn)定主線版本拢锹。
- feature-1從release copy出來進(jìn)行開發(fā)。
- feature-2從release copy出來進(jìn)行開發(fā)萄喳。
- feature-2在開發(fā)期間需要使用feature-1的新功能卒稳，且在feature-1上線前就要使用（feature-1 在 feature-2前上線），所以需要把feature-1 同步到feature-2上他巨。
錯誤操作
- feature-1 merge到了feature-2中充坑。
- feature-1 繼續(xù)后續(xù)開發(fā)，開發(fā)完成后 merge 回release染突，發(fā)布release捻爷。
- feature-2 開發(fā)完成后，merge回release時份企，在feature-1中新增的文件（feature-2中未修改）產(chǎn)生了tree conflict也榄。
產(chǎn)生conflict原因分析：feature-1 merge進(jìn)feature-2后，相當(dāng)于feature-1的改動在feature-2上實(shí)現(xiàn)了一遍司志，會生成一個新的Revision = X甜紫；然后將feature-1 merge進(jìn)release降宅，feature-1的改動會在release上生成一個新的Revision = Y（X != Y，兩者除了Y比X大其他沒有任何關(guān)系囚霸，可以理解為兩次單獨(dú)的修改）腰根；后續(xù)feature-2 merge 到 release時，對于在feature-1中新增的文件拓型，相當(dāng)于在兩個不同的Revision中额嘿，該文件都被新建，所以產(chǎn)生了tree conflicts吨述。
正確操作
- 從release中copy出feature-3
- 將feature-1 merge 到feature-3
- 從feature-3 中copy出 feature-4 來進(jìn)行feature-1 的后續(xù)開發(fā)岩睁，完成開發(fā)后merge回release。
- 將feature-2 merge到 feature-3中揣云，在feature-3中繼續(xù)feature-2的開發(fā)。
核心理念
不要把feature merge到兩個分支中冰啃，同時這兩個分支后續(xù)還需要進(jìn)行merge邓夕，這樣會出現(xiàn)沖突。因?yàn)橄喈?dāng)于兩個分支上各自進(jìn)行了feature的開發(fā)阎毅，兩者并無關(guān)聯(lián)關(guān)系焚刚，雖然merge來源一致。
