分支模式/政策

我目前正在修改我們商店的版本控制方式。我們將使用以服務器爲中心的版本控制解決方案。分支模式/政策

我想看看其他人是如何分支，併成功地做這件事，沒有我所瞭解的頭痛。

在生產環境中看到的一些經過現場測試的分支模式可以很好地工作，即每個版本分支。已經制定了什麼政策來確保分支順利進行。

由於

來源

2009-06-19 jon37

這取決於你正在開發什麼樣的軟件。

對於我們來說，我們是一家網上商店，所以我們沒有任何編號的「發佈」。我們保留樹幹作爲'生產'的價值，只能直接進行小的改變。

當我們有一個大的項目，我們創建一個分支，它工作到生產準備，所有的同時同步主幹的修改進去。

如果項目涉及大量的重組代碼庫的，我們一般會合並分支修改之前創建的最後一次修訂的標籤。

再一次，如果你正在創建打包軟件，你需要維護不同的版本，這將不會有效。

爲了記錄在案，我們使用。

來源

2009-06-19 22:02:44

我們是一家網上商店，所以我認爲這樣的模式會很棒。 – jon37 2009-06-19 23:33:15

的subversion book描述了一些常用的分枝模式（例如發佈分支，功能分支等）。

來源

2009-06-19 21:52:18 M4N

這是我們做的方式，它的工作原理很適合我們......

Project 
    | 
    +--01-Development 
    | | 
    | +--Release1.0 
    | | | 
    | | +--Solution Files 
    | | 
    | +--Release2.0 
    |  | 
    |  +--Solution Files 
    | 
    +--02-Integration 
    | | 
    | +--Release1.0 
    | | | 
    | | +--Solution Files 
    | | 
    | +--Release2.0 
    |  | 
    |  +--Solution Files 
    | 
    +--03-Staging 
    | 
    +--04-Production

以及你的想法...

注：這是團隊基礎的目錄結構服務器分支僅存在於01-開發/發佈1.0和02-集成/發佈1.0, 02-集成/發佈1.0和03-發佈/發佈1.0, 03-暫存/發佈1.0和04-生產/Release1.0

換句話說，你將無法合併03-Staging/Release1.0到04-Production/Release2.0等...

這對我們有什麼作用是我們有4個獨立的環境開發，集成（Alpha服務器），分段（測試服務器），生產。

代碼開始開發開始發展，然後，因爲它通過QA（集成/阿爾法）和用戶（分期/測試）測試，最後到生產被提升。

收集功能/更改並將其分組爲每幾個月發佈的版本。

但讓我們說你正在爲Release2.0開發，並且你在Release1.0上得到了一個生產問題......我可以很容易地獲得最新版本的Release1.0，並且修復這個問題並且在不影響任何我一直在爲Release2工作。0

不會說這會適用於所有情況下的每個人，但這對我們來說非常有效。

來源

2009-06-19 22:03:28 bytebender

3考慮分支的事情。

第一：只要您打算稍後合併事物，分支就很好。當然，您可以隨時爲您的某位客戶提供具有特定補丁的分支機構，並解決特定問題。但最終你想要將大部分補丁合併回主幹線

第二：認定你的需求。我已經看過各種規模的樹，具體取決於部門的規模，客戶的數量等等。

第三：檢查你的源代碼控制對於分支和合並有多好。例如，對於這種操作，CVS非常糟糕。 SVN，「他們聲稱CVS做得對」，稍微好一點。但是創建Git的Linus Torvalds（這對於這種操作來說特別好）會告訴你CVS無法做到正確（他在Git上的一個非常有趣的演示中說過）。所以如果你真的需要分支和合並，至少得到SVN而不是CVS。

來源

2009-06-19 22:13:27 Ksempac

看一看分支模式：

http://www.cmcrossroads.com/bradapp/acme/branching/

它描述了許多的模式與模式工作。我通常工作在兩個方面：

穩定接收線 - 所有的開發是在分支完成，僅在需要時合併到主幹。這意味着你總是有一個穩定的發佈點。
主要開發線 - 所有的工作都在後備箱內進行。當涉及到釋放你採取釋放標籤，並使用它。如果需要進行重大實驗返工，則在分支中進行並在穩定後合併回主幹。

來源

2009-06-19 22:54:23 Jon

分支模式/政策

回答

相關問題