「樓梯」分支的好處是什麼？

Question

我遇到過使用樓梯分支的項目。爲了澄清，這是代碼被分支用於開發和開發完成的方法，而不是切回到主幹/主線，開發分支被指定爲實時代碼集並從中取出新的分支。這繼續無限。

我個人比較喜歡減少幹線方法來維護一個單一的「實時」代碼集。不過，我想知道樓梯方法是否有任何競爭優勢。

感謝， 湯姆

Answer 1

當你想創建多個分支並同時對它們進行開發時，這種方法會在derriere中咬你。合併回樹幹可以讓您擁有平行分支，並且可以輕鬆地將它們集中在一個分支上。

Answer 2

有一對夫婦的（可能較小的）這種做法的好處。

最引人注目的好處來自於無需將更改合併回主分支。這使得爲​​分支的版本保留一個分支（舊的「trunk」）很容易，同時也不需要開發分支繼續工作。實際上，這與帶有一個活動主幹並標記或分支發行版沒什麼兩樣，但是除了「移動」您的開發而不是移動標記的分支之外。這可以使得用更少的努力維護清潔分支變得更容易，因爲不需要爲每個發佈「標記」新分支 - 它只是自動發生。儘管如此，這只是一個小小的節省時間。

不過，根據我的經驗，有一個潛在的缺點。我經常發現，這種方法通常會讓開發人員意外地破壞庫中的二進制兼容性，因爲你總是在開發一個副本，每個「發佈」都是一個獨立的分支。由於不需要重新合併到主幹，因此可能很容易意外中斷API。這不是國際海事組織的主要問題，但需要注意，因爲在合併過程中沒有任何努力（這似乎是大多數這些錯誤經常被發現的地方）。

Answer 3

我相信這是一種讓回滾更容易，並且版本之間的差異更清晰一些的方法。繼續開發以前的版本也很容易（例如，爲開發人員提供版本，爲設計人員提供版本）。

我自己更喜歡帶有指示檢查點的標記的其他方法。我使用git，分支和做這種東西的過程是非常好的。

Answer 4

從第一個階梯開始，您處於開發第一個版本時的相同位置。 這個是它，關於什麼回到主幹沒有遲到的決定。樓梯的建造是你最新的人選。

處罰，如果很多變化和修復原來你已經合併做，這可能是破壞性的。我猜測，如果新版本的變化率和舊版補丁的速度使樓梯不夠理想，可能會有盈虧平衡點。