本文無條理性，僅作自我參考。

花費(fèi)了兩個(gè)半下午，走馬觀花的看了一下說明文檔，SVN設(shè)計(jì)的太復(fù)雜，對(duì)我這樣的，不在一個(gè)集體的的業(yè)余開發(fā)者，要理解起來真是太難了。。。。??

---

?

分支

Make branches as often as you want.（這是SVN官方說明中的一句話）

There's nothing special about this working copy; it simply mirrors a different directory in the repository.

版本控制系統(tǒng)的一個(gè)特性是能夠把各種修改分離出來放在開發(fā)品的一個(gè)分割線上。這條線被稱為分支。分支經(jīng)常被用來試驗(yàn)新的特性，而不會(huì)對(duì)開發(fā)有編譯錯(cuò)誤的干擾。當(dāng)新的特性足夠穩(wěn)定之后，開發(fā)品的分支就可以混合回主分支里(主干線).

假設(shè)已經(jīng)建立分支，如果其他人的?working?copy 在trunk上，當(dāng)你提交分支的更改時(shí)，主干不會(huì)發(fā)生改變。

分支背后的關(guān)鍵概念：You should remember two important lessons.

First, Subversion has no internal concept of a branch—it knows only how to make copies.When you copy a directory, the resultant directory is only a “branch” because you attach that meaning to it. You may think of the directory differently,or treat it differently, but to Subversion it's just an ordinary directory that happens to carry some extra historical information.
在版本庫中的復(fù)制，都是“廉價(jià)復(fù)制”。

Second, because of this copy mechanism, Subversion's branches exist as normal filesystem directories in the repository. This is different from other version control systems, where branches are typically defined by adding extra-dimensional “l(fā)abels” to collections of files. The location of your branch directory doesn't matter to Subversion. Most teams follow a convention of putting all branches into a /branches directory, but you're free to invent any policy you wish.

合并(保持分支同步)

　　------frequently keeping your branch in sync with the main development line helps prevent “surprise” conflicts when it comes time for you to fold your changes back into the trunk.

由于有眾多的人參與項(xiàng)目，大多數(shù)人擁有主干拷貝是很正常的，任何人如果進(jìn)行一個(gè)長(zhǎng)周期的修改會(huì)使得主干陷入混亂，所以通常的做法是建立一個(gè)私有分支，提交修改到自己的分支，直到這階段工作結(jié)束。所以，好消息就是你和Sally不會(huì)互相打擾，壞消息是有時(shí)候分離會(huì)太遠(yuǎn)。

記住“閉門造車”策略的問題，當(dāng)你完成你的分支后，可能因?yàn)樘鄾_突，已經(jīng)無法輕易合并你的分支和主干的修改。

相反，在你工作的時(shí)候你和Sally仍然可以繼續(xù)分享修改，這依賴于你決定什么值得分享，Subversion給你在分支間選擇性“拷貝”修改的能力，當(dāng)你完成了分支上的所有工作，所有的分支修改可以被拷貝回到主干。在Subversion術(shù)語里，這種從一個(gè)分支復(fù)制修改到另一個(gè)分支的活動(dòng)稱為合并，它是使用svn merge命令執(zhí)行。

?

svn merge另一個(gè)常用的做法

是取消已經(jīng)做得提交，假設(shè)你愉快的在/calc/trunk工作，你發(fā)現(xiàn)303版本對(duì)integer.c的修改完全錯(cuò)了，它不應(yīng)該被提交，你可以使用svn merge來“取消”這個(gè)工作拷貝上所作的操作，然后提交本地修改到版本庫，你要做得只是指定一個(gè)相反的區(qū)別。(你可以通過指定--revision 303:302--change -303

svn merge與svn ?diff

......At this point, the wise thing to do is look at the changes carefully with svn diff, and then build and test your branch. Notice that the current working directory (“.”) has also been modified; the svn diff will show that its svn:mergeinfo property has been either created or modified. This is important mergerelated metadata(元數(shù)據(jù)) that you should not touch, since it will be needed by future svn merge commands.

但是svn merge沒有這樣的保證，會(huì)導(dǎo)致很多的混亂：用戶可以詢問服務(wù)器比較任何兩個(gè)樹，即使一個(gè)與工作拷貝毫不相關(guān)的！這意味著有潛在的人為錯(cuò)誤，用戶有時(shí)候會(huì)比較兩個(gè)錯(cuò)誤的樹，創(chuàng)建的增量數(shù)據(jù)不會(huì)干凈的應(yīng)用，svn merge會(huì)盡力應(yīng)用更多的增量數(shù)據(jù)，但是有一些部分也許會(huì)難以完成，就像Unix下patch命令有時(shí)候會(huì)報(bào)告“failed hunks”錯(cuò)誤，svn merge會(huì)報(bào)告“skipped targets”：

指出svn diff和svn merge區(qū)別的重要性在于，前一個(gè)命令忽略祖先，如果你詢問svn diff來比較文件foo.c的版本99和102，你會(huì)看到行為基礎(chǔ)的區(qū)別，diff命令只是盲目的比較兩條路徑，但是如果你使用svn merge是比較同樣的兩個(gè)對(duì)象，它會(huì)注意到他們是不關(guān)聯(lián)的，而且首先嘗試刪除舊文件，然后添加新文件，輸出會(huì)是一個(gè)刪除緊接著一個(gè)增加。

如果你使用svn merge進(jìn)行比較，你會(huì)看到第一個(gè)目錄樹被刪除，而第二個(gè)樹添加上！在這個(gè)情況下，你僅僅是希望svn merge以路徑為基礎(chǔ)比較兩棵樹，而忽略文件和目錄的不相關(guān)性，當(dāng)為合并命令添加--ignoreancestry選項(xiàng)時(shí)，就會(huì)像svn diff一樣工作。

?

切換

“Switching” a working copy that has no local modifications to a different branch results in the working copy looking just as it would if you'd done a fresh checkout of the directory. It's usually more efficient to use this command, because often branches differ by only a small degree. The server sends only the minimal set of changes necessary to make your working copy reflect the branch directory.

?

svn switch命令改變存在的工作拷貝到另一個(gè)分支，然而這個(gè)命令在分支上工作時(shí)不是嚴(yán)格必要的，它只是提供了一個(gè)快捷方式。在前面的例子里，完成了私有分支的建立，你取出了新目錄的工作拷貝，相反，你也可以簡(jiǎn)單的告訴Subversion改變你的/calc/trunk的工作拷貝到分支的路徑。

?

svn switch命令也可以帶--revision(-r)參數(shù)，所以你不需要一直移動(dòng)你的工作拷貝到分支的HEAD。
當(dāng)然，許多項(xiàng)目比我們的calc要復(fù)雜的多，有更多的子目錄，Subversion用戶通常用如下的法則使用分支：
1. 拷貝整個(gè)項(xiàng)目的“trunk”目錄到一個(gè)新的分支目錄。
2. 只是轉(zhuǎn)換工作拷貝的部分目錄到分支。

切換和更新

Have you noticed that the output of svn switch and svn update looks the same? The switch?command is actually a superset of the update command.

svn switch是svn update的一個(gè)變種，具有相同的行為，當(dāng)新的數(shù)據(jù)到達(dá)時(shí)，任何工作拷貝的已經(jīng)完成的本地修改會(huì)被保存。

?當(dāng)你運(yùn)行svn update時(shí)，你會(huì)告訴版本庫比較兩個(gè)目錄樹，版本庫這樣做，并且返回給客戶區(qū)別的描述，svn switch和svn update兩個(gè)命令唯一區(qū)別就是update會(huì)一直比較同一路徑。That is, if your working copy is a mirror of /calc/trunk, svn update will automatically?compare your working copy of /calc/trunk to /calc/trunk in the HEAD revision. If?you're switching your working copy to a branch, svn switch will compare your working copy of?/calc/trunk to some other branch directory in the HEAD revision.換句話說，一個(gè)更新通過時(shí)間移動(dòng)你的工作拷貝，一個(gè)轉(zhuǎn)換通過時(shí)間和空間移動(dòng)工作拷貝。

?If the working copy needs to reflect（映射） a new directory within the repository, use just svns witch.If the working copy still reflects the same repository directory, but the location of the?repository itself has changed, use svn switch with the --relocate option。

另一個(gè)Subversion模型的可愛特性是分支和標(biāo)簽可以有有限的生命周期，就像其它的版本化的項(xiàng)目，舉個(gè)例子，假定你最終完成了calc項(xiàng)目你的個(gè)人分支上的所有工作，在合并了你的所有修改到/calc/trunk后，沒有必要繼續(xù)保留你的私有分支目錄。

在我們的例子里，你的個(gè)人分支只有一個(gè)相對(duì)短的生命周期：你會(huì)為修復(fù)一個(gè)Bug或?qū)崿F(xiàn)一個(gè)小的特性來創(chuàng)建它，當(dāng)任務(wù)完成，分支也該結(jié)束了。在軟件開發(fā)過程中，有兩個(gè)“主要的”分支一直存在很長(zhǎng)的時(shí)間也是很常見的情況，舉個(gè)例子，假定我們是發(fā)布一個(gè)穩(wěn)定
的calc項(xiàng)目的時(shí)候了，但我們?nèi)詴?huì)需要幾個(gè)月的時(shí)間來修復(fù)Bug，你不希望添加新的特性，但你不希望告訴開發(fā)者停止開發(fā)，所以作為替代，你為軟件創(chuàng)建了一個(gè)“穩(wěn)定”分支...。

??

---

?

?

SVN可以為一個(gè)版本庫中的內(nèi)容(主干)建立一個(gè)分支.分支和主干完全獨(dú)立，就相當(dāng)于把代碼再復(fù)制（便宜復(fù)制）一份，重新添加到版本庫中。但SVN提供另一個(gè)功能，就是把主干做出的修改合并到分支中，以及把分支修改的內(nèi)容合并到主干中。當(dāng)然，我們也可以把主干的版本庫的路徑切換到分支上，然后更新，來實(shí)現(xiàn)把分支的修改更新到主干；以及修改分支路徑來同步主干的修改。但過程復(fù)雜，還容易出錯(cuò)。

1.將一個(gè)整項(xiàng)目建一個(gè)分支.

選擇要復(fù)制的源位置有三個(gè)選項(xiàng)：

　　版本庫中的最新版本
　　　　新分支直接從倉庫中的最新版本里復(fù)制出來。不需要從你的工作副本中傳輸任何數(shù)據(jù)，這個(gè)分支的建立是非常快的。
　　在版本庫中指定具體的版本
　　　　在倉庫中直接復(fù)制建立一個(gè)新分支同時(shí)你也可以選擇一個(gè)舊版本。假如在你上周發(fā)布了項(xiàng)目時(shí)忘記了做標(biāo)記，這將非常有用。如果你記不起來版本號(hào)，通過點(diǎn)擊鼠標(biāo)右鍵來顯示版本日志，同時(shí)從這里選取版本號(hào)。和上次一樣不需要從你的工作副本中傳輸任何數(shù)據(jù)，這個(gè)分支建立起來是非常快的。
　　工作副本
　　　　新的分支是一個(gè)完全等同于你的本地工作副本的一個(gè)副本。如果你更新了一些文件到你的工作副本的某個(gè)舊版本里，或者你在本地做出了修改，這些改變將準(zhǔn)確無誤的進(jìn)入副本中。自然而然地這種綜合的標(biāo)記會(huì)包含正在從工作副本傳輸?shù)桨姹編斓臄?shù)據(jù)，如果這些數(shù)據(jù)還不存在的話。

?

注意:是否把主干的路徑切換到新分支（把的工作副本自動(dòng)切換到最新創(chuàng)建的分支）

　　如果勾選了，建立分支后，在主干里做出的修改并提交后，更新會(huì)提交到分支上。主干的版本源內(nèi)容不會(huì)變.

　　但是如果你打算這么做，首先要確認(rèn)你的工作副本沒有被修改。如果有修改的話，當(dāng)你轉(zhuǎn)換后這些修改將會(huì)混合進(jìn)你的工作副本分支里。按下確認(rèn)提交新副本到版本庫中。別忘了提供一條日志信息。需要注意的是這個(gè)副本是在版本庫內(nèi)部創(chuàng)建的。

?

為了避免產(chǎn)生困惑。以及失誤。建議在建立的時(shí)候不要勾上 "切換到分支" 的選項(xiàng)。如果勾上了，我們還是切換回去:

這時(shí)你便可以在 /calc/branches/my-calc-branch 分支上開發(fā)新的功能，且不會(huì)影響到其他成員開發(fā)或維護(hù)主干的內(nèi)容。

切換操作起來就象更新，因?yàn)樗鼪]有丟棄你在本地做的修改。在工作副本里當(dāng)你進(jìn)行切換的時(shí)候任何沒有提交過的修改都會(huì)被混合。如果你不想看到這樣的結(jié)果，那么你可以有兩種選擇，要么在切換前提交修改，要么把工作副本恢復(fù)到一個(gè)已經(jīng)提交過的版本(比如最新版本)。

?

?

?

2.合并主干的變更到分支上

經(jīng)常將 開發(fā)主干 ( /calc/trunk ) 的變更透過 svn merge 合并至 分支 ( /calc/branches/my-calc-branch )是一個(gè)非常好的習(xí)慣，這樣才不會(huì)讓你脫離主干(trunk) 過久而導(dǎo)致將分支 ( /calc/branches/my-calc-branch) 合并回 主干 ( /calc/trunk ) 時(shí)發(fā)生許多沖突。?

?

?從主干 ( /calc/trunk ) 合并至分支 ( /calc/branches/my-calc-branch ) 通常選第 1 個(gè)，也就是 [Merge a?range of revisions]

注意.我們是在分支上使用的 Merge 功能.因?yàn)槭且诜种蠎?yīng)用主干的更新.

?

?

在 Merge 的窗口有以下注意事項(xiàng)：

1.合并的來源，由于我們打算從主干 ( /calc/trunk ) 合并至分支 ( /calc/branches/my-calc-branch )，所以合并的來源要選 /calc/trunk 才對(duì)！
2.合并的結(jié)果會(huì)直接與目前「工作目錄」(Working Copy) 做比對(duì)，并修改目前工作目錄中的所有文件。因此建議在做合并之前可以將所有尚未 commit 的檔案先 commit 到版本庫，避免不必要的沖突事件發(fā)生。

?

在正式進(jìn)行合并(Merge)之前，建議先執(zhí)行 Test merge 看看是否會(huì)發(fā)生什么事!

若無異狀則可直接按下 [Merge] 按鈕進(jìn)行合并動(dòng)作，這時(shí)從 主干 ( /calc/trunk ) 分支出來的到目前工作目錄的版本就會(huì)做個(gè)比較，然后直接套用變更到你現(xiàn)有的文件、目錄或?qū)傩岳铩?/p>

?

在合并之后如果沒有發(fā)生沖突，不代表真的沒沖突，所以必須再次對(duì)原始碼做出驗(yàn)證后才能 commit 進(jìn)版本庫，
建議可參考以下流程：
1.將項(xiàng)目進(jìn)行建置(Build)
2.如果沒問題再對(duì)項(xiàng)目進(jìn)行單元測(cè)試(Unit Testing)或手動(dòng)測(cè)試(Manual Testing)
3.如果都沒問題再 commit 目前合并無誤的版本到版本庫！

?

If you encounter serious problems, you can always abort the local changes by running svn revert .

3.合并分支到主干

最后我們的 my-calc-branch 分支已經(jīng)將新功能開發(fā)完成且測(cè)試無誤，所以要將 分支 ( calc/branches/mycalc-branch ) 的最終版本合并回 主干 ( /calc/trunk )，這時(shí)的手續(xù)如下：

?

??

?

從 分支 ( /calc/branches/my-calc-branch ) 合并回 主干 ( /calc/trunk ) 通常選第 2 個(gè)，而特別選擇[Reintegrate a branch] 這個(gè)選項(xiàng)是很重要的，因?yàn)檫@有以下好處：
1.讓 Subversion 能知道 主干 ( /calc/trunk ) 是從哪個(gè)分支、哪些版本合并進(jìn)來的
2.有效節(jié)省 Subversion Repository (SVN儲(chǔ)存庫) 的空間，因?yàn)椴挥弥貜?fù)儲(chǔ)存分支的所有變更信息
3.可以產(chǎn)生 Revision graph 得知項(xiàng)目開發(fā)的分支狀況

?

一樣可以先 測(cè)試合并(Test merge) 再正式進(jìn)行 合并(Merge)

?

?

4.合并完后再將變更 commit 到版本庫

?

?

4.刪除使用完畢的分支

當(dāng) 分支 ( /calc/branches/my-calc-branch ) 合并回 主干 ( /calc/trunk ) 并 commit 了之后，該分支就沒
用了，該分支如果未來不再更新或繼續(xù)開發(fā)，Subversion 也不會(huì)繼續(xù)追蹤這個(gè)分支的變更 (因?yàn)橹耙呀?jīng)
Reintegrate 過了)，建議將該分支刪除。

?

?

沒有必要繼續(xù)保留你的私有分支目錄。刪除已經(jīng)完成的分支避免其他人繼續(xù)使用該分支開發(fā)，減少版本庫的復(fù)雜程度。

?

?

另參考：http://www.cnblogs.com/dabaopku/archive/2011/05/21/2052820.html

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/InspiringMind/p/4661093.html

總結(jié)

以上是生活随笔為你收集整理的SVN 分支/合并/切换的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。