功能/錯誤版本的SVN最佳實踐是什麼？

Question

我一直在StackOverflow上閱讀幾個問題，但我並不十分滿意。我在這種情況如下：

大型Web應用程序項目（複雜的零件，幾未知）：

幹線是主要的穩定版本

分支有BUG的版本如bug-503，bug-524，其中一些錯誤是複雜的，涉及多個文件，其他錯誤不是很多，有些會得到修復，然後重新訪問多次。

標籤我主要使用的標籤不同的版本中，我們有三種環境：生產，沙箱和DEV ...標籤發行有助於保持一個版本號跨ENVS一致，以便在任何時候，我們可以比較環境正在使用的版本號

因此，我沒有在分支機構中完成大部分工作，併合並回主幹並生成標籤發佈。開發環境通常具有所有最新的錯誤修復/添加的構建。通常有關於開發環境的評論，某些特徵/錯誤被認爲是穩定的，此時我將這些特定功能合併到主幹中。其他人被審查，可能需要更多的工作，在這種情況下，我會進入特定的分支並進行調整。

我感覺到的痛苦是我有dev和trunk，我必須將特性/ bug分支合併到每個中。看起來如此複雜和繁瑣。 我做得對嗎，有沒有更好的方法/練習，更簡單的練習？或者我完全錯了，在這種情況下，我需要更好的方法！

Answer 1

說實話你的做法對我來說似乎很好，說如果一個bug不會花費很多時間/代碼，那麼我會建議只檢查一下dev並在那裏做修復，然後檢查修復版本庫dev。

還有一個原因，你需要一個始終穩定的主幹？開發人員多久開發一次，以確保始終擁有穩定的主幹？你應該刪除等式的開發部分，只是檢查一切進入樹幹，然後確保樹幹如果損壞即時修復。這將使開發過程變得更容易。只是想讓你的生活更輕鬆。

Answer 2

我更喜歡這樣的場景：

• 開發樹幹爲了微不足道的變化，或在較大件工作的一個特點/ bug修復分支。
• 也有環境分支和發佈版本。例如「生產」，「階段」
• 標籤應該是最終的，即不要委託給標籤。

所以，一個例子生命週期：

發展

• 做一些developent在樹幹和樹枝中的bug-1，錯誤-2，功能1和功能2。驗證錯誤和功能後，將穩定的合併到主幹中（例如合併bug-1，bug-2和功能-1）。

功能齊全：

• 一旦你準備階段，你可以分支主幹到分支「舞臺」的代碼，曾經是在舞臺的任何代碼將通過主幹代碼來代替。舞臺系統總是運行階段代碼的構建，以便測試。發展可以繼續在主幹和功能/ bug分支。

發佈：

• 一旦階段分支足夠穩定，您可以在跳轉到發佈分支。將它分支到名爲「release-1.X」的分支，現在將該修訂標記爲「release-1.0.0」。生產服務器可以運行release-1.0.0標籤的版本。不要對此標籤提交任何內容。

修正：

• 如果您發現生產代碼中的錯誤，你可以修復它的樹幹，在各階段的合併修改到發佈1.X分支，然後標記固定發佈版本爲1.0.1，並指示生產服務器運行此新版本的構建版本。