我們公司最近使用TortoiseSVN作爲我們的客戶將版本控制系統切換到SVN，以便於使用敏捷開發方法。我們的SVN存儲庫在主幹上有多個分支，每個sprint都有一個分支。我們通常做「保持最新的樹幹，然後重新整合分支」的方法。但是，有時需要將分支中的更改移植到主幹或其他分支！ （如錯誤修復）。我們有一個不斷髮展的bug修復分支（如果可能的話，我想保留它作爲分支，所以幹線可以保持「純」）。TortoiseSVN/Subversion - 分支到中繼線的定期合併
如果我定期合併一系列從分支到主幹的修訂版，然後在完成我們的一組錯誤修復後重新將分支集成到主幹，這是否可行？我不想將兼併的東西加倍。永遠不要重新整合合併，而只是繼續進行一系列修訂？我們正在使用SVN 1.6。
，如果我從 分支合併一個版本範圍的定期，然後 重新整合分支時，我們的 集bug修正完成主幹，將這個 工作主幹？
是的，它會工作。
我不想雙重合並東西。
由於你使用Subversion 1.6，只要該svn:mergeinfo property不被篡改，Subversion會跟蹤什麼變化，已合併，合併只是那些沒有變化。
它會更好，以永遠不會做 重返社會，而不是合併，只是 繼續做修改的範圍是多少？
你可以做任何一個。但是我會建議你進行重新合併合併，除非你將補丁或熱補丁移動到主幹或其他分支。
從分支合併到分支時需要注意有關修補程序或熱修復的注意事項：如果熱修復或修補程序具有新對象（文件和/或目錄），請小心。有時這些可能會導致樹型衝突，在分支被釋放後移植到樹幹中，然後從樹幹更新其他樹枝，這可能會導致合併或重新集成的痛苦。 Subversion 1.6.x和相關客戶端在合併過程中處理這個問題，但老客戶端不會。
+1，我肯定總是喜歡在將分支完全合併回主幹時重新合併。重新整合有很多安全檢查。 – 2010-12-22 01:54:49
兩個問題：
你運行多個不相關的衝刺在一個發佈週期？
在每個發佈週期完成後，您是否將發佈標籤發佈爲上次發佈的產品版本？
如果您對第一個問題的答案是肯定的，那麼對於多個分支以及從分支到分支的定期合併都是有意義的。如果您定期或每次發佈標籤發行版，可能會導致冗餘運行分支，並將trunk作爲「最新版」開發版本，包括錯誤修正。因人而異。
是（對這兩個問題），至少那是計劃。我們仍然有點過渡，但我認爲這是我們的目標。 – 2010-12-21 18:22:32
我發現這[淹沒的博客文章]（http：//blogs.open.collab。net/svn/2008/07/subversion-merg.html）對於理解svn中的合併非常有幫助。它從1.5開始，但仍然適用。 – 2010-12-22 01:56:10