Hg倉庫的'默認'分支應該怎麼做？

Question

在大自由報源碼軟件項目，用水銀或類似的DVCS工具版本，以下哪項被認爲是更傳統的：

1. 在default分支保持軟件的最新的「穩定」版本。在default中標記每個發行版，以便知道哪些修訂版本打包爲下載。一旦測試完成，將補丁合併到default。在下一個版本中，將命名分支中的新功能等合併到default中。
2. 保持命名分支中的每個版本或類似版本。使用default來保持最初的代碼只能由開發人員或非常魯莽的人運行。

還是...有，它被廣泛接受的工作流程的一些更好的模式？

Answer 1

水銀對你應該用你的default分支一個相當強烈的意見。它記錄在Standard Branching wiki page。總結如下：

• 您的主開發分支不應使用除default以外的名稱。

  原因是default是由新克隆檢出的分支。如果您嘗試爲「主」分支使用其他名稱，那麼當用戶克隆並在錯誤位置提交內容時，用戶會得到或多或少的隨機分支，這通常是不合需要的。

  即使有大量文檔說「添加新功能之前的分支」（請參閱​​下一點），但人們在向您發送補丁時會忘記這一點。然後他們通過移動變化集合來清理事物。

  因此，請始終將出血端代碼放在default分支中，並將其他分支用於穩定版本。

• 不要把分支名稱爲一次性

  分公司名稱是每次提交永久組成部分，允許識別每個提交引入哪個分支上。因此，您需要考慮一下分支名稱，以免污染分支名稱空間。

  此外，如果您嘗試使用每個bugfix的分支，最終可能會遇到性能問題。 Mercurial及其周圍的工具可以與數百個分支機構配合使用。 Mercurial本身仍然能夠很好地支持一萬個分支，但是一些命令可能會顯示出明顯的開銷，只有在您的工作流程穩定後才能看到。

  我們在Mercurial內部使用了緩存，所以問題主要是UI問題：託管站點和日誌查看器可能運行hg branches將所有10,000個分支加載到單個下拉菜單中。對於想要從巨大菜單中選擇單個分支的窮人，這非常慢並且毫無用處。

  如果分行關閉，那麼他們不會出現在hg branches，所以問題應該最小化。但是，這些工具可能也想顯示關閉分支 - 這一切都取決於該工具。

  對不起，這有點含糊。主要的一點是Mercurial是按照變更集的數量來構建的，而不是指定分支的數量。我們已經解決了我之前提到的帶有緩存的命名分支的最大性能問題，所以今天我並不太在意擁有多個分支，特別是如果開放分支的數量保持較少（小於100）。

Answer 2

有沒有，在常見的，這樣的東西作爲「最傳統」 - 每一個工作流程是當地慣例和團隊發展政策的問題。

我看到經常提到的兩個政策，以及中間的變化 - 也。

如果測試發佈策略和密集使用的分支（「每個任務的分支」）「默認」分支通常僅作爲合併分支（在QA測試之前從功能分支合併）並且意味着「代碼，它可以處理完成的功能，而不會引發錯誤，但功能未經檢驗「。

次要版本形成評爲分公司，分公司等每一個版本的標籤。漏洞修復分支完成到「默認」和現行版本的分支

後合併但這工作流程只是一個例子，不是更好|比別人，適用於中等規模的團隊與責任分離成立更糟的是，不井「混亂的無政府狀態」的發展

Answer 3

我如果有使用水銀默認和掌握Git中的實際工作中，最前沿，並使用該版本的標籤和分支陷入習慣工作。 hgsubversion和Git-Svn似乎採取了這種方式。

Answer 4

這並不是一個巨大的數額。如果我們正在談論DEV & STABLE分支，這是默認的主要只是一個命名約定。我傾向於將DEV設置爲默認值，這是因爲大多數工作都發生在開發分支上，並且如果這是默認分支，那麼它就不那麼昂貴。

個人而言，我喜歡每一個版本命名分支。錯誤修復然後可以在這些分支上進行，並且在使用hg merge後可以相對容易地向所有版本移植。如果你試圖用DEV和STABLE做同樣的事情，你只能擁有一個維護版本（最後一個版本），或者你的穩定分支開始增長分支，並且最終每個版本的分支版本（可能組織更少）結構體。