大重構後的git rebase

我有2個分支，master和featureA。在featureA分支中，我在CoolFile.m中編寫了一堆新代碼。該功能尚未完成，因此此代碼尚未準備好合併到主設備中。 CoolFile過去寫得很差，所以在開發分支中，我對它進行了一系列更改（主要是重新排序方法，添加註釋和刪除空白）。大重構後的git rebase

現在我想要重設功能關掉主設備，這樣我就可以從清理好的代碼中受益。問題是，由於所有的方法都已經移動，rebase正試圖將所有新代碼放在錯誤的地方。解決這個問題的最好方法是什麼？我應該等到功能完成重構嗎？

來源

2011-05-30 Christian Schlensker

你可以合併來自主分支的變化到您的featureA分支，

A--B--F--G--H master 
    \ 
    \-C--D--E featureA

讓我們假設你犯B於主創建featureA，而C，d和E的提交上featureA和F製成和G是對方法進行重新排序的提交等。您現在想要做的是將F和G合併到featureA分支中。

$ git checkout featureA 
$ git merge G (G is the sha1)

或者，你可以櫻桃選擇提交F和G到featureA。請記住，您仍然會發生衝突，並且這些只是您的重新選擇選項的替代方案。

在未來，我會建議你做重構直接上featureA，或從另一個分支，從featureA分支：

A--B--F--G--H master 
    \ 
    \-C--D--E featureA 
     \ 
      \-I--J--K refactorFeatureA

然後，它的一塊蛋糕在重構分支合併進入featureA，因爲合併將是微不足道的。

來源

2011-05-30 22:38:20 ralphtheninja

我明白了你的意思，我通常會在我的featureA分支中完成重構，但是我還有另一個使用此相同文件的主功能分支。特徵A是一個很大的功能，在featureA完成之前，我可能會有更多的分支從master創建。這就是爲什麼我在主人做重構的原因。 – 2011-05-31 02:38:42

我可能是錯的，有點像git newb，但rebase的工作方式是找到來自原始分支（本例中爲master）的子分支的最近共同祖先，然後應用新提交然後是子分支的新提交到子分支上（換句話說，就好像你獲得了最新的主分支，然後重新創建你的分支，通過提交來提交）。所以等待會對你不好，因爲它會應用來自兩個分支的所有提交。

我覺得最好的辦法就是讓這只是硬着頭皮做合併。與您一起獲取其他開發人員，以便您可以選擇要解決合併衝突的代碼。

我還發現，使提交小使得重新融合/合併更容易。所以，不要重構x函數，然後提交，在每次重構之後提交。它的真正目的是找到一個平衡點 - 不要承諾每一行更改，但在有意義時儘可能小地提交提交。

來源

2011-05-30 22:29:46 hvgotcodes

如果你有一堆這些小提交，你會不會有一大堆不明顯的評論在你的歷史？像「移動方法A，移動方法B，移動方法C等......」 – 2011-05-31 02:35:24

@christian，關於「重構 - 移動方法A」不明顯？另外，我只是說，我發現小的提交和不斷的重新綁定使得這個過程變得更容易，而不是任何人都必須這樣做。 – hvgotcodes 2011-05-31 12:53:36

大重構後的git rebase

回答

相關問題