在項目中使用樹幹，分支和標籤

Question

我知道理論，但從實際的角度來看，svn如何用於項目？說，我有一個網站的功能將被修改或添加。在什麼情況下會使用新的中繼線，分支和標籤？

Answer 1

我會說一個單一的樹幹，其中「穩定」非常小的變化（也許是小錯誤修復），不會破壞你的構建。

分支應該用於新功能/大的更改。分支機構應保持最新狀態，並在分支機構運行時對其進行更改。

一旦你的新功能已經完成，分支應該合併回主幹，然後可以刪除分支。

標籤用於發佈。例如v1.2

Answer 2

不同的組織可以做非常不同的事情。 Alex給出的解決方案是一個常見的解決方案，但遇到的問題是，只有在着陸分支後纔會發現其他分支與您的分支有衝突。這會導致人們必須調整他們在一段時間內沒有看過的東西中的衝突。

我遇到的另一種常見方法是在trunk中進行所有開發，並使開發人員使所有提交變得很小，獨立，提交。有多種添加功能的方法，默認情況下它是不可見的，但在開發副本中打開。使用它們。這種方法需要開發者的關注，但是避免了處理壽命較長的分支之間的衝突所帶來的痛苦。

很多使用Alex的解決方案的人會上下跳動，並說：「除了一個小團隊之外，這絕不會適用於任何事情！」爲此我回應說，小團隊沒有任何問題，他們的生產力通常遠遠超過大型團隊所能做的。如果開發者有紀律，那麼該策略可以擴展，例如Google使用它。如果您想查看使用該策略的實際項目，請查看http://llvm.org/。

還有一些建議。如果你想遵循Alex的策略，我強烈推薦使用git而不是svn。它比svn處理分支要好得多。如果您想遵循我建議的策略，並且您的團隊不是與您信任的人組成的小團隊，則需要使用代碼審查工具（如http://code.google.com/appengine/articles/rietveld.html）來減少可能出現的明顯問題。

Answer 3

看一看這兩篇文章：

http://www.snuffybear.com/ucm_branch.htm

http://www.vance.com/steve/perforce/Branching_Strategies.html

從SnuffyBear的鏈接講更多有關你似乎想僱用，而關於其他戰略other article談判策略如通過發佈分支。每篇文章都概述了每種策略的優缺點。

Answer 4

我的卑微觀察：合併分支是可怕的。在很多情況下，不同開發人員所做的更改是完全分開的，因此可以順利合併。但是在任何繁忙的項目中，都會有變化衝突的時候。如果幸運的話，SVN會識別衝突並在合併時給您提供錯誤。如果你不那麼幸運，SVN不會捕獲它，但它不能編譯。無論哪種方式，有人現在必須弄清楚如何將這些改變放在一起。有時這是顯而易見的。但是我已經有過很多次，我不得不讓開發人員一起做出改變，所以我們可以弄清楚做什麼。

如果你非常不走運，SVN和編譯器都不會看到問題，衝突的更改將投入生產，並且程序的行爲不正確。

從這個觀察我得出兩個結論：（a）儘可能少的分支。或者更準確地說，制定儘可能少的合併策略。 （b）在代碼尚未完成測試時進行合併。

一段時間我的公司有一個分支策略，說每個項目都有自己的分支，經過該分支的測試，當我們準備部署到生產環境時，我們合併了要包含在該版本中的所有分支，編譯和部署。這原來是一個非常糟糕的主意。有人會在部署前一天嘗試解決合併衝突，並且合併結果從未經過測試。很多微妙的錯誤悄然進入生產。

對於我們使用這種策略：大多數開發是在樹幹中完成的。當一個版本準備好交給測試組時，我們就剝離一個分支。然後在下一個發行版中繼續工作。當前版本的任何錯誤修復都在分支中完成，並且此分支中的更改定期合併回主幹。有時候需要在3個發行版上同時進行工作，即一個發行版正在測試中，另一個正在接近準備測試，現在我們需要從下一個發行版開始。在這種情況下，我們會有測試分支，當前版本的trunk，以及下一版本的「pre」分支。當前版本進入測試組時，我們會將「pre」分支合併到trunk中，併成爲當前版本。

我們最近開始嘗試一種略有不同的策略。當一個版本正在測試中時，我們仍然剝離一個單獨的分支。但是測試中出現的任何修復都是在主幹中完成的，然後這些修復從主幹合併到測試分支中。這意味着所有的開發工作都發生在主幹上，合併總是從主幹到其他地方。這有兩大好處：其一，開發人員總是使用主幹進行測試，所以我們對主幹中的代碼是好的更有信心。測試組將測試發佈分支，所以我們有信心發佈分支是好的。也就是說，我們有信心兩個分支都會被測試。在分支中進行更改併合並回主幹時。幾乎沒有人保證任何人都會測試合併的結果。二，樹幹總是有每個模塊的完整「責備」歷史。當你從分支合併回樹幹時。樹幹中的歷史記錄將從分支到合併人員的所有變化歸因於所有變化，而不是真正進行變更的人員，並且評論往往是無意義的「從brach xyz合併而來」。當你從樹幹合併到分支時，確保分支現在顯示「錯誤」的人並且沒有信息的評論，但樹幹有很好的歷史記錄。有一個地方可以去追尋歷史，而不是追逐分支。