你是繼續在樹枝上還是在樹幹裏開發？

Question

假設您正在開發定期發佈的軟件產品。關於分支和合並的最佳做法是什麼？定期向公衆發佈分支機構（或者你的客戶），然後繼續開發主幹，或者考慮將主幹版本作爲穩定版本，定期將其標記爲發佈版本，並在分支機構中進行實驗性工作。人們認爲樹幹被認爲是「黃金」還是被認爲是「沙箱」？

Answer 1

我曾嘗試與大型商業應用這兩種方法。

答案哪種方法更好高度依賴於您的具體情況，但我會寫什麼我的整體體驗迄今所示。

更好的方法整體（在我的經驗）：主幹應該始終保持穩定。

下面是這種方法的一些指導和好處：

• 代碼每個任務（或相關的任務集）在自己的分公司，那麼你將有靈活性，當你想合併這些任務並執行發佈。
• QA應在每個分支之前被合併到主幹完成。
• 通過對每個單獨的分支做QA，你就會知道到底是什麼導致了這個bug更容易。
• 該解決方案適用於任何數量的開發人員。
• 此方法可行，因爲分支在SVN中幾乎是即時操作。
• 標記您執行的每個版本。
• 您可以開發你不打算釋放了一段時間，準確地確定何時將它們合併功能。
• 對於您所做的所有工作，您可以享受提交代碼的好處。如果您僅使用主幹，則可能會使您的代碼很長時間沒有提交，因此無法保護，也沒有自動歷史記錄。

如果你嘗試做相反，做在樹幹所有的發展你有以下問題：

• 恆建問題的每日構建
• 生產力損失時AA開發商承諾項目上所有其他人的問題
• 更長的發佈週期，因爲您需要最終獲得穩定版本
• 不太穩定的版本

如果您試圖保持分支穩定，並將幹線作爲開發沙箱，您將不具備所需的靈活性。原因是你不能從主幹中選擇你想要在穩定版本中放置什麼。它已經全部混在一起了。

特別是我要說的一件事情，那就是在開始一個新項目時，要在幹線中進行所有開發。根據您的情況，可能還有其他情況。

---

順便說一下，分佈式版本控制系統提供了更多的靈活性，我強烈建議切換到hg或git。

Answer 2

幹線通常是主要的開發線。

版本被分支出去，通常在分支上完成實驗或主要工作，然後在準備與主要開發線集成時重新合併回主幹。

Answer 3

我傾向於採取「發佈分支」的方法。幹線是不穩定的。一旦發佈時間臨近，我會創建一個發佈分支，我會更仔細地對待它。當最後完成時，我會標記/標記存儲庫的狀態，以便知道「官方」發佈的版本。

我知道還有其他方法可以做到這一點 - 這是我過去做過的。

Answer 4

我認爲你的第二種方法（例如，標記版本和在分支中做實驗性的東西，考慮到幹線穩定性）是最好的方法。

應該清楚的是，分支機構在分支時繼承了系統的所有錯誤：如果修補程序應用於中繼線，如果您維護分支機構，則必須逐個去所有分支機構作爲一種釋放週期終止符。如果您已經有20個版本，並且您發現了一個可以追溯到第一個版本的錯誤，那麼您將不得不重新應用您的修補程序20次。

分支應該是真正的沙盒，儘管幹線也必須扮演這個角色：標籤會指示代碼在該時間點是否爲「黃金」，適合發佈。

Answer 5

樹幹通常應該是您的主要開發源。否則，您將花費大量時間合併新功能。我看到它以其他方式完成，通常會導致很多最後一刻的集成問題。

我們將發佈的標籤貼上標籤，以便我們可以快速響應生產緊急情況而不會分發活躍的開發。

Answer 6

我們在主幹上進行開發，除非這些變化太重大，不穩定，或者我們正在接近我們產品的主要版本，在這種情況下，我們會創建一個臨時分支。我們還爲每個單獨的產品版本創建一個永久分支。我發現微軟的文檔Branching Guidance相當有幫助。 Eric Sink的tutorial on branching也很有趣，並指出微軟可能對我們其他人來說過於沉重。在我們的案例中，我們實際上使用了Eric所說的他的團隊所採用的方法。

Answer 7

試圖管理與新開發一致的當前生產代碼的維護問題充其量就是問題。爲了減輕這些問題，一旦測試工作完成並且代碼準備好交付，代碼應該分入維護線。另外，主線應該分支以協助釋放穩定，包含試驗開發工作，或者容納生命週期延伸到多個版本的任何開發工作。

只有在代碼之間存在碰撞的可能性（或確定性）時，才應該創建非維護分支，否則難以以其他方式進行管理。如果分支機構不解決後勤問題，它將創建一個。

正常版本開發發生在主線上。開發人員檢查進出正常發佈工作的主線。針對當前生產代碼的修補程序的開發工作應該位於該發行版的分支中，並在修補程序通過測試並部署後與主線合併。非維護分支機構的工作應根據具體情況進行協調。

Answer 8

對我來說，這取決於我使用的軟件。

在CVS下，我只會在「trunk」中工作，並且從不標記/分支，因爲這樣做非常痛苦。

在SVN中，我會在trunk中執行我的「流血邊緣」的東西，但是當它是做服務器推送的時候，要適當地標記。

我最近切換到git。現在我發現我從來沒有在後備箱工作。相反，我使用一個名爲「新功能名稱」的沙箱分支，然後合併成一個固定的「當前生產」分支。現在我想到了，我真的應該製作「release-VERSIONNUMBER」分支，然後再合併到「當前製作」中，這樣​​我就可以回到較舊的穩定版本...

Answer 9

這取決於您的情況。我們使用Perforce，通常有幾個開發線。幹線被認爲是「黃金」，所有的發展發生在分支上，當它們足夠穩定以便整合時，它們被合併回主線。這允許拒絕不切割的特徵，並且隨着時間的推移可以提供獨立的項目/特徵可以獲得的穩定的增量能力。

融合和追趕到樹幹中的新功能的整合成本，但你會遭受這種痛苦無論如何。讓每個人都在軀幹上一起發展可能會導致一種狂野的西方情況，而分支可以讓你縮放並選擇你想要服用苦藥的點數。目前，我們已經將十多個開發人員擴展到了一百多個開發人員，每個開發人員都使用相同的核心組件進行多個版本的開發，並且工作得很好。

這樣做的好處是你可以遞歸地做到這一點：一個大功能分支可以是自己的樹幹，如果它與其他分支脫落。此外，最終版本會獲得一個新分支，爲您提供一個穩定維護的地方。

Answer 10

如果你要完成一個發佈週期，大功能，你會被困在一個分支。否則，我們在樹幹中工作，並在我們構建的時刻爲每個生產版本分支。

以前的生產版本當時被移動到old_production_，並且當前版本始終只是生產版本。我們所有的構建服務器都知道生產是如何部署生產分支的，我們用強制觸發器來啓動生成。

Answer 11

這取決於您的開發工作量。並行工作的多個團隊將無法有效地使用相同的代碼（中繼）。如果你只有一小部分人在工作，並且你的主要擔心是切割一個分支，那麼你可以繼續工作，同時回到分支去修正當前生產代碼的錯誤。這是分支的一個簡單的使用，不是太繁重。

如果你有很多並行開發，你會想爲每個努力都有分支，但是這也需要更多的紀律：確保你的分支經過測試並準備好合併回來。調度合併，所以兩個組不會嘗試同時合併等。

有些分支正在開發中，所以您必須允許從主幹到分支進行合併，以便在最終合併回主幹時減少意外數量。

如果你有一大羣開發人員，並且瞭解你的情況有效，你將不得不進行實驗。下面是微軟的一個頁面，可能是有點用處：http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Answer 12

我已經同時使用了這兩種技術，我會說在幹線上發展並將穩定點作爲發佈分支是最好的方法。

那些人以上誰反對說，你必須：

• 恆建問題的每日構建
• 生產力損失時AA開發商提交一個問題，所有 其他人對項目

可能沒有使用過持續集成技術。

確實，如果你不在白天進行多次測試，每隔一小時說一次，就會對這些問題置之不理，而這些問題很快就會扼殺開發的步伐。

在白天快速完成多個測試版本，可以在主代碼庫的更新中進行摺疊，這樣其他人就可以使用它，並且還可以在白天警告您是否有人破壞了構建，以便他們在回家之前修復它。如前所述，只有在夜間構建運行迴歸測試失敗時發現破損構建失敗純屬愚蠢，並會迅速減慢速度。

閱讀Martin Fowler關於Continuous Integration的論文。我們用大約2000行Posix sh將我們自己的這種系統推廣到一個重大項目（3,000kSLOC）。

Answer 13

我們遵循trunk =當前開發流，branch = release（s）方法。在發佈給客戶時，我們將樹幹分支並保持樹幹向前滾動。您需要決定您準備支持多少個版本。您支持的越多，您將在錯誤修復方面進行更多合併。我們試着讓我們的客戶在主幹後面保留不超過2個版本。 （例如Dev = 1.3，支持版本1.2和1.1）。

Answer 14

一個關於保持樹幹穩定並且在分支機構都能正常工作的開發過程的很好的參考是Divmod的Ultimate Quality Development System。簡要總結：

• 做必須有一個
• 對於其中爲票工作完成
• 從該分支的更改不會合並回每張票是創建一個新的分支相關聯票的所有工作爲不被其他項目成員

所評論的主線樹幹他們使用SVN這一點，但是這可能很容易地與任何分佈式版本控制系統來完成。

Answer 15

@Brian R. Bondy：請注意，一旦您的團隊達到了在項目中並行處理的一定數量的ppl /任務，這不是一個解決方案。

一旦QA部門參與QA，每個分支進行一次安裝所需的工作量就太高了。認爲SOA /客戶端/服務器/ Web服務/數據庫所有必須提供每個分支。

該解決方案缺乏整合階段。

Answer 16

我們使用主幹進行主開發，分支進行版本維護工作。它工作很好。但是之後的分支只能用於bug修復，沒有什麼重大變化，特別是在數據庫方面，我們有一條規則，只有主幹上可以發生模式變化，而不會發生在分支上。

Answer 17

兩者。

幹線用於大多數的發展。但預計將盡最大努力確保對主幹的任何入住手續不會打破。 （通過自動構建和測試系統進行部分驗證）

版本保留在其自己的目錄中，只對其進行了錯誤修復（然後合併到主幹）。

任何將使主幹處於不穩定或非工作狀態的新功能都會在其自己的單獨分支中完成，然後在完成時合併到主幹中。

Answer 18

我們使用的方法是Perforce的方法，這是在長度勞拉Wingerd的偉大的書討論：

http://oreilly.com/catalog/9780596101855/index.html

雖然這本書是Perforce的中心（Wingerd是Perforce公司產品經理），概念可以應用於任何或所有VCS。

perforce方法（和平臺）爲我們提供了很好的服務。它在很多公司都用過（谷歌，Intuit，我聽說過，微軟Windows本身）。

這本書很值得一讀。

Answer 19

閱讀：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 20

有沒有一個放之四海而皆準的所有答案顛覆慣例的問題恕我直言。

這確實取決於項目和公司使用它的動態。在一個非常快節奏的環境中，當每隔幾天發佈一次發佈時，如果您試圖虔誠地標記和分支，最終會得到難以管理的存儲庫。在這樣的環境中，分支機構何時需要的方法會創建更加可維護的環境。

此外 - 根據我的經驗，從純粹的管理角度來看，在您選擇時可以在svn方法之間切換，非常容易。

我已經知道最好的兩種方法是分支時需要的，分支每個任務。這些當然是彼此完全相反的。就像我說的 - 這完全是關於項目動態。

Answer 21

這實際上取決於您的組織/團隊管理版本以及您使用的SCM的程度。

• 如果下一步（在下一個版本中）可以很容易地計劃，你最好在後備箱中開發。管理分支需要更多時間和資源。但是如果下一步不能很容易地規劃（在大型組織中一直髮生），你可能會選擇櫻桃提交（數百/數千）而不是分支（幾十或幾十）。
• 使用Git或Mercurial，管理分支比CVS和顛覆更容易。我會選擇穩定的主幹/主題分支機構方法。這是git.git團隊使用的。閱讀：http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• 在Subversion中，我首先應用了trunk-in-the-trunk methodlogy。在發佈日期方面有相當多的工作，因爲每次我必須選擇提交（我的公司不擅長計劃）。現在我是Subversion的專家，對Subversion中的管理分支非常瞭解，所以我正在朝着穩定的中繼/主題分支方法發展。它比以前好得多。現在我正在嘗試git.git團隊的工作方式，儘管我們可能會堅持使用Subversion。

Answer 22

我喜歡並使用Henrik Kniberg在Version Control for Multiple Agile Teams中描述的方法。 Henrik在解釋方面做得非常出色，如何在多個團隊的敏捷環境中處理版本控制（在傳統環境中也適用於單個團隊），並且沒有必要對他進行解釋，因此我只需發佈「備忘單」 （這是自解釋）如下：

我喜歡它，因爲：

• 這很簡單：你從圖片中可以得到它。
• 它工作（和規模）很好，沒有太多的合併和衝突的麻煩。
• 您可以隨時發佈「工作軟件」（本着敏捷的精神）。

以防萬一它不夠明確：開發工作在「工作分支」中完成，幹線用於完成（可釋放）代碼。查詢Version Control for Multiple Agile Teams的所有細節。

Answer 23

這裏是SVN的設計，我更喜歡：

• 根
  • 發展
    • 分支
      • 特徵1
      • 特點2
      • ...
    • 幹線
  • 測試
    • 標籤
    • 幹線
  • 發佈
    • 標籤
    • 幹線

所有的工作都從開發/軀幹完成，除了要求自己的分公司主要特徵。在對開發/主幹進行測試後，我們將測試的問題合併到beta/trunk中。如有必要，代碼將針對測試版服務器進行測試。當我們準備推出一些更改時，我們只需將適當的修訂合併到release/trunk和deploy中。

標籤可以在beta分支或發佈分支中製作，因此我們可以跟蹤beta和release的特定發佈。

該設計考慮了很多靈活性。如果某些修訂版未通過beta測試，它還使我們可以輕鬆地在beta/trunk版本中保留修訂版，同時合併其他版本以釋放/ trunk。