如果我們發現某些分支中的bug,我們修復它(檢查新的發佈在圖片上)。而且我們在此修復程序移動到老釋放和主要開發分支有趣:如何在DVCS中的分支中移動錯誤修正?
a-->b-->c (Old release) | A-->B-->C-->D (Main release) | 1-->2-->bugfix-->4 (New release)
SVN記得的svn:合併特性(從SVN 1.6,2009年),其修訂合併到分支。因此,下次如果合併版本的區域,則合併修補程序會從合併修補程序中跳過。
如何處理現代DVCS?
我需要做一個普通的補丁,並將其應用到每個分支或存在DVCS的幫助嗎?
注意:我不能只是合併新領域,以主要如先前的變更也移動到主要領域。
Rebase也不可能作爲新版本發佈給許多開發者。
我有興趣回答命名分枝模式和多庫模式。
PS。Andy建議找到所有分支機構的共同家長,這些分支機構對其有影響,更新,修復bug並將修復移到受影響的分支。
通過更新舊的變更集並進行更改,您可以創建新的分支。我建議創建命名分支(將其命名爲bugID),以便稍後可以輕鬆地回到它。
找到我們有興趣修復錯誤的所有分支的共同父項存在問題。
首先溶液(暗示安迪)使用$ HG/git的/的bzr怪並仔細檢查輸出爲所有受影響的文件。這涉及到一些最新的變更集首先修復bug,然後再找到責怪什麼變更引入了一個錯誤。然後你需要rebase修復(補丁)到共同的父變更集。
另一種解決方案是使用$ hg/git/bzr bisect(您也可以手動執行更新以查找引入錯誤的第一個修訂版)。這可以是廣闊的,但更多true解決方案允許填充錯誤修正爲任何分支中存在錯誤。
我想還是先找到第一BAD變更,然後修正錯誤,而不是先修復bug,然後找到第一BAD變更(除情況下,當你已經知道如何修復的bug)。也有介紹差異可以幫助理解爲什麼會發生。
PPS。有了bug,很清楚哪個分支影響到允許合併更改到任何受影響的分支。
有趣的問題來問如何從開發分支backport功能發佈分支。如您所見,您必須提交在發佈分支之前以changeset開頭的功能更改集。但是,當你開發功能時,你可能不知道你需要什麼backport功能。用svn:合併 VCS記住你所有的backports。如何DVCS?
git cherry-pick? –
櫻桃挑選可能會導致您的歷史混亂,如果他們曾經合併回來。 – Andy
@安迪:怎麼樣的困難? –