處理分支和合並的更好方法？

Question

我們在任何給定時間運行一個網絡開發商店，共有約20位開發人員在大約30個不同的網站上工作，我們正在耗費大量的時間來管理我們的Subversion存儲庫 - 必須有更好的方法。

我們的客戶站點通常有3個獨立的部署環境：開發（中繼），分段（分支）和生產（分支）。

新功能在開發過程中得到內部審查，然後與分期合併以供客戶審覈和批准，最後合併到生產中。

我們目前的工作流程：每個爲客戶開發主要新功能的開發人員都會從主幹創建一個分支，處理他們的功能，同時定期從主幹進行更新，然後將這些更改合併回主幹（開發）供內部審查。開發人員正在進行微小的更改或修復，將使他們直接在主幹中。

內部簽退後，所做的更改將被合併爲暫存。如果需要進行更改，則通常會在後備箱中進行更改，然後合併到分段中。一旦獲得批准，這些更改將與生產合併，然後進行部署。

新功能不會在內部或客戶端按順序審查，整個事情變得相當混亂。看來我們正在使用錯誤的流程 - 必須有更好的方法來做到這一點。我們對如何更好地利用版本控制非常感興趣，但我們缺乏啓動過程的經驗。

這些場景的最佳做法是什麼？除了這個論壇之外，我們有興趣聘請一位有經驗的顧問，他可以幫助我們改進我們的流程。

謝謝！

Answer 1

我認爲branching by feature（或團隊）會比開發商分支更好。該功能可以在通過開發（Trunk）合併到暫存分支之前進行測試和預覽。

我的團隊有一個類似的「質量/環境分支」結構，我花了幾個月的時間研究如何最佳轉換，以便開發人員共同合作，我們可以減少合併稅。我建議如下：

• 發展（中繼線/主/根分支）
  • （FeatureName1 [版本]） - 爲每個開發人員替換分支。
  • 分期（如果要保持在一個分支上的所有版本）
  • 生產
  • （ReleaseName）（MajorVersion）分段 - 通過我的喜好來隔離不同的版本，即使釋放到同一環境
  • （ReleaseName）（版）的生產

分期修復程序在臨時支直接由（或分期的短命子分支，如果QA和/或危險的任務隔離），然後合併修復回到發展（中繼線）作爲洙ñ修復被接受。 注意：在臨時修復正在進行時，密切關注來自Development的任何合併。

從質量保證角度看，我強烈希望最終階段性測試版本是發佈到生產環境中的相同二進制文件/文件。唯一的變化應該是配置文件（將不同的配置設置簽入存儲庫）。這意味着我通常會在「分段」中進行最終構建，而「生產」或ReleaseVersion分支是沒有人構建的只讀存檔。 （如果所述標籤不可變，則可以使用標籤或標籤代替此保管分支...對於TFS 2010，情況並非如此:-(。）

請參閱2011年2月的Visual Studio TFS Branching and Merging Guidance MSDN文章中的酷圖。 爲了擴展這一點看Branching for Scrum和Parallel Feature Teams working on multiple releases in development. Monthly releases to production.。這兩個附帶適用於任何版本控制系統的一些優秀的圖表。

我也建議看TFS Branching Guide在這同一位置的討論論壇額外好模式和指導（分支方法在很大程度上與工具無關，避免工具缺陷時除外）

我看到在原來的分支過程的至少一個根本缺陷：

內部簽字之後，所做的更改，然後合併分期。如果需要進行更改，則通常會在後備箱中進行更改，然後合併到分段中。

如果在開發中對暫存進行了更改，然後再次合併到暫存，那麼您剛剛繼承了自上次合併到暫存以來對開發分支所做的所有其他更改。或者如果您選擇了更改（將所有其他更改稍後合併）。 SCM工具在處理這種情況下越來越好，但挑選合併仍然帶來重大風險。參考文獻：

僅供參考：最初描述的模式與Jeff Levinson所描述的「Branch By Quality」類似。它可以工作，但您必須仔細查看如何管理修補程序/ qfe分支並將更改合併回Trunk。

Answer 2

而不必分期和生產單獨的分支，你可能要考慮以下方法：

每個開發者始終工作過後備箱，當它是時候把它變成分期，您創建一個標記，指示代碼進入臨時環境的快照。

如果您的客戶批准，那麼您可以繼續前進，並將相同的標籤推到生產中。

如果他們不贊成（比如說，他們發現了一個bug），那麼您只需繼續使用主幹並使用錯誤修復創建另一個標籤。

注意：由於SVN沒有'標記'的強制概念，'標記'本質上是一個分支，你仍然可以提交代碼。但是，不得 alter（即，提交）您創建的標籤關閉主幹。

Answer 3

你可能會考慮改成Git而不是Subversion。 Git非常好地支持這種分支模型，並且非常輕巧。這需要一點時間適應，特別是如果你從Subversion轉移，但最終它會給你帶來很多。

一個建議Git的工作流程中的新功能可能是：

1. 創建一個分支關閉行李箱。
2. 實現功能分支上的功能，包括內部審查的迭代。
3. 當客戶簽署新功能時，將分支合併到主幹和生產中，並（可選）刪除分支。

您並不需要爲此工作流設置臨時分支。您也不需要在合併功能分支時保留它們--Git會記住更改歷史記錄。

該模型支持異步/亂序功能開發和審查相當好，因爲每個功能分支本質上是獨立的。

分支在Git中非常便宜，合併通常非常簡單。

Answer 4

你並不完全說它是如何變得混亂，但我猜測這是每個人都將它們的功能分支合併回主幹的時候。我建議這是一個工作流程：

1. 每個人都在爲下一個部署工作，並定期提交;只有採用多個週期或者可能不會包含在下一個交付中的功能應該在單獨的分支上工作。我們將這些開發分支稱爲開發分支，並且應該在開發週期開始時進行合併 - 而不是結束。

2. 當您準備好階段時，創建一個發佈分支。繼續作爲下一個版本的主幹，合併到針對下一版本的任何開發分支中。此時，錯誤修復可能必須從分支合併回主幹，但只有錯誤修復和功能開發應該添加到分支上，所以它不應該太糟糕。實際上，爲了減少不必要的合併，我們通常會暫停創建發佈分支，直到我們準備好開始開發新功能。

3. 當需要將代碼轉移到生產環境中時，只需標記發佈分支並繼續使用它即可。使用此分支來維護此版本的代碼，直到您的所有客戶站點都將其替換爲下一個版本。

這種模式，你的軀幹發展，每次發佈保持在一個單一的分支都非常好，我們的環境中，我們有時有客戶希望修復到很老版本的軟件。