功能分支中的錯誤修復

我們使用Vincent Driessen的A successful Git branching model作爲我們的分支模型。一切都很好，但我還沒有真正看到過一個特別的問題。功能分支中的錯誤修復

從我所瞭解的情況來看，當需要一個新功能時，您需要分支development並創建一個新的feature分支。您可以在此完成，當您完成後，您會將此分支合併到development分支中。

如果開發人員創建了一個功能，然後將該功能合併回development，那麼只有發現功能代碼中存在一些錯誤時該怎麼辦。這應該在哪裏解決？是否應該從開發中啓動一個新的分支並在那裏修改代碼？我看不到另一種方式。

應該怎麼辦？

感謝

2011-08-30 Mridang Agarwalla

我似乎以創建您的問題的副本，但在我的問題中，我採取了提供命令來創建實驗回購測試概念的方法：http://stackoverflow.com/questions/32244693/changes-on-feature-分支合併到母版/ 32244878？noredirect = 1＃comment52371049_32244878 您介意我是否用範例回購擴展您的問題，並看看如何將建議的答案實際應用於該回購以及結果如何？ – TheMeaningfulEngineer

請記住，模型只是一個模型 - 它是關於給你一個結構，使你更有效率，而不是盲目遵循一組規則。這意味着你可以隨意調整事物並找出適合你的情況，因爲它可能在任何情況下都不起作用。

我認爲你必須在這種情況下一個選擇：

回滾合併，並繼續關注的分支工作，直到它準備
開始一個新的分支，以修復bug。

你選擇哪一個取決於類似因素：

你的客戶可以看到錯誤？製作修補程序或修補程序分支。
錯誤是否真的很糟糕，並阻止開發分支的其他進展？回滾更改。
它只是一個小問題，對外部影響最小？只需繼續使用功能分支，並在準備就緒後再次合併。

從Git的角度來看，功能分支和bugfix分支之間的區別並不重要。如果您將這些標籤用於內部文檔或其他審覈目的（例如跟蹤外部用戶可見的內容），那麼這一點很重要。

即使您認爲bug修復速度非常快，您也可以抵制開發分支的工作 - 任何事情都不會像看起來那麼簡單，而且如果出現任何問題，您將會很頭痛。您的選擇

粗糙的可視化表示：

State machine diagram of choices

來源

2011-08-30 06:33:34

如果該功能分支爲一公共（即被推到克隆遠程回購/被他人使用），最好是做一個新的分支，並在隔離調試說修復分支。
（而不是試圖在'develop'分支上重新分配'feature'分支）。

該想法仍然不直接在develop分支中記錄中間調試落實，而是僅記錄最終提交，它將首先解決feature分支合併引入的錯誤。

來源

2011-08-30 05:56:32 VonC

只需創建一個分支（或使用舊的，合併的feature分支）並將其修復。

使用舊的分支/創建新的分支是一樣的---你不能命名哪個是合併後的。

來源

2011-08-30 06:08:28

如何finding the commit that introduced the bug, and creating a new branch rooted there？使用這種方法：

有沒有創造由於變基操作
單從開發分支，特性分支和其他分支可能會受到影響的祖先破引用的風險，你可以告訴哪裏一旦完成，你應該合併你的bugfix分支。即使「特徵」自引入錯誤以來多次與「開發」合併，情況也是如此。
如果您確定引入該錯誤的提交以及來自那裏的root，開發人員將能夠確定他們需要合併bugfix分支的位置，即使他們不熟悉回購佈局
您會有一個分支，你可以合併，而不用擔心拉入不相關的後續變化。例如，假設有人正在研究「功能-β」，這是「功能」的一個子分支，在引入錯誤後不久就分歧了。他們可以輕鬆地引入bugfix分支，而不必擔心引入「feature」上發生的其他任何事情。
這種方法減少了需要摘櫻桃，它有它改變提交的名稱下跌（從而破壞了Git的巨大優勢之一，其應用了明確的名稱的一切。）

來源

2012-05-17 22:14:35 gcbenison

+1000。我也認爲這是最可取的方法。它導致了非常明確的提交歷史記錄。另一方面，櫻桃採摘是最不透明的方法，因爲它完全隱藏了引入臭蟲的位置和固定位置。還要注意，git bisect在尋找引入錯誤的提交方面有很大的幫助。肯定是一個高度建議的方法。 –

功能分支中的錯誤修復

回答

相關問題