2016-12-29 109 views
1

我一直在閱讀git分支工作流程,似乎有一個假設,分支在那裏用於開發目的,一切都最終被合併回主。我無法找到關於使用長期運行的分支來維護舊版本的討論。使用git來維護舊版本

例如,下面是我的工作流程如何在SVN中工作(基於perforce「豆腐」模型)。假設最新發布的版本是4.1,但我也支持版本4.0,3.5和3.6,因此每個版本都有一個維護分支。 Trunk用於在4.2版之前不會發布的功能。現在說客戶需要對版本3.6進行錯誤修復。我將修復到我的3.6維護分支並做出新的維護版本(爲了參數,3.6.22)。

在這一點上,修補程序向下合併到4.0,從那裏到4.1,4.2和主幹,並從那裏,到任何由樹幹製作的開發分支。請注意,這不是一個櫻桃選擇合併;這是一個正常的SVN自動合併。

如果修復不重要,我們可能會從3.6發行版分支創建一個開發分支,然後在發佈之前以正常方式重新集成它。同樣,如果4.1的合併不是微不足道的,我們可以從4.1開發一個開發分支到合併,然後在我們對合並感到滿意時重新合併到4.1版本。

當我們發佈4.2版本,我們將分出一個維護分支爲以同樣的方式,和軀幹將開始進行4.3工作

我應該(或者甚至可以一)在Git中使用完全相同的工作流程,還是這個「舊帽子」的傳統svn思想需要重新考慮?

+0

實際上,除了每個發佈的代碼行至少保留1個分支以外,沒有別的選擇。我在perforce和git上描述了這個工作(好的,整合團隊有時候會讓它變得更復雜xD) –

+0

你可以使用git'tag'(輕量級),然後如果你需要對特定版本進行修復,你可以使用標籤創建一個新的分支,否則它將保持原樣。 – Deep

回答

3

根據版本控制技術,分支策略並沒有真正改變太多。您所描述的內容聽起來像是實況產品的標準分支工作流程。從SVN等其他工具轉移到Git的變化是創建和維護分支的成本。在Git中,分支非常便宜。 Git中的分支基本上只是一個指向提交的指針。因此,例如創建一個僅包含少量提交的維護分支的成本將會增加很少。 SVN這樣的工具可能不是這種情況,可能需要創建項目中的副本或每個文件。