我應該爲每個報告的新bug創建一個新分支嗎？

Question

我們使用JIRA作爲我們的票務系統。新錯誤/故障單會提交給該系統。一旦修正了一個錯誤，我們創建一個新的構建並在我們的開發服務器上進行測試。如果一切順利，我們將它推送到實時服務器。現在我通常在沒有任何分支來修復bug的情況下工作在主幹上。這當然是一個問題。因爲我們的系統中可能存在很多錯誤，但一次只能修復某些錯誤。但是，如果我將它們全部修復在樹幹而不是分支中，那麼即使我們沒有足夠的時間來測試它們，我們也不得不測試它們。你通常如何修復錯誤和分支等。？ （我不確定我是否解釋得很好）。

Answer 1

這是我使用的策略。我在主幹道上發展。當軟件發佈時，我將它分支（比如v1.0）。當錯誤進入時，修復分支樹幹，然後合併回主幹。這裏有一個很好的可用策略大綱：http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html

Answer 2

我不確定這是否是正常的策略，但我們都在樹幹上工作，然後將錯誤修復反向移植到發佈分支中。我們的主幹總是「不穩定」，當我們覺得我們的主幹處於可釋放狀態時，我們將其分支到發佈分支。從那時起，buyfixes被移植回發行版分支，新功能只被添加到主幹中。這意味着您可以通過測試來運行您的發佈分支，並專注於測試錯誤修正。

Answer 3

我不會推薦分支上的每個報道錯誤。正如你所說，你可能不會決定修復所報告的每一個bug，這意味着你會有很多死枝修剪。

如果你的工具&語言支持它，分支你決定修復的每一個bug（並且你決定實現的功能）並不是一個壞主意。它允許您在有預算和時間表時開發和測試每個錯誤修復/功能，並在您準備好時將它們合併回主幹。

Answer 4

一種常見操作模式是部署的軟件位於一個單獨的分支中，該分支僅接收錯誤修正。實際開發這些修補程序的地方大多不相關;爲了避免干擾當前的開發，在「實時」分支之上開發修補程序，然後測試/提交/部署到實時系統，然後將修復合併回主幹是合理的。

Answer 5

我們將分支機構分成產品版本/版本，以便每個版本都有自己的分支。測試分支的發佈，因此我們只需測試應用於該分支的修復。

此外，每個產品版本都有一個dev和一個主分支。開發人員可以自由地提交到Dev分支，而不必擔心與釋放干擾的（唯一的其他開發商！）

Answer 6

我們有同樣的問題（或差不多），我認爲每一個開發團隊有它。不幸的是，我還沒有給你一個經驗答案，而只是一個理論答案。

在我看來，只要它是一個bug修復，應儘快部署。 我要實現的是功能分支策略和發佈分支。這意味着我們必須區分bug和bug。並且部署的內容是單獨分支的（或者在我們的例子中標記爲

）這樣做，您仍然可以在缺陷的trunk上工作，並將它們部署到您的測試服務器上，一旦它被測試並批准，發佈分支並部署它。 您還可以將錯誤修復合併到您的功能分支中，或者在計劃將其部署到測試服務器時嘗試合併此功能。

無論如何，我認爲最重要的是分支長期的工作，阻止您部署較小的錯誤修復。 如果您分支太多，您將遇到合併問題。如果分支不夠，您將會遇到部署靈活性問題。

Answer 7

除非您使用分佈式SCM（Mercurial，Git，...），其中分支基本上是免費的，否則分支每個錯誤聽起來像是不合理的工作量。

中央存儲庫SCM的通常策略是記錄應該修復該錯誤的修訂版，並針對使用較新版本進行的構建進行測試。然後，您可以將相關修訂合併回發佈分支。

我們正在使用水銀，並分支到修復bug，然後合併更改回是在分佈式SCM

Answer 8

這取決於你的版本控制系統非常可行的。如果你使用的是git，分支很便宜，合併很容易，那麼我肯定會爲每個修補創建一個新的分支。這使您可以保持相互獨立的錯誤修復，從而在合併到主/中的時間和時間方面提供更大的靈活性。另一方面，如果你使用的是Subversion，分支更加昂貴（在創建和切換/更新方面），合併更加困難。通常新分支的成本/收益比率不夠高（特別是對於小錯誤）以使其值得。