git rebase onto的多種用法

我不是git專家，所以我經常在git中學習會改變我對該工具看法的東西。當顯示git rebase -i，我停止了對提交的思考。當我發現git reflog，我對重新部署變得更加自信。但是我認為我被教過的最重要的命令之一是git rebase --onto。

恕我直言，該檔案在選擇結果方面仍有改進的餘地。如果拍攝樹的影象，它基本上會將樹的一部分連根拔起，然後將其重新種植到其他位置。

讓我們用以下樹為例：

o---o---o---o master \\---o---o branch1

\\---o branch2

假設我們要將branch2從branch1移植到master：

o---o---o---o master \ \ \ \---o' branch2

\\---o---o branch1

這是乙個很好的用例！在分支branch2，命令為git rebase --onto master branch1。這大約意味著將所有內容從branch2開始，從branch1移至master的尖端。我通過記住第乙個引數是新提交，第二個引數是舊提交來記住語法。

所以，但是有什麼用例可以移動樹的一部分呢？

雖然我要刪除提交的第乙個反射是git rebase -i，但它並不總是最方便的。它需要執行以下步驟：

找到要刪除的第乙個提交

有效地執行git rebase -i命令

在編輯器中，對於每個需要刪除的提交，刪除該行

退出編輯器

如果要刪除的提交是相鄰的，則將rebase --onto更容易，因為您只需要新的和舊的提交，並且可以在一行中進行「刪除」。

這是乙個例子：

o---a---x---y---z master

要刪除最後3個提交x，y和z，您只需要：

git rebase--onto a z

擁有長期存在的分支通常是乙個壞主意，但有時是必需的。

假設您需要將應用程式的一部分遷移到新框架，庫等。對於小型應用程式，可以由乙個小型工作隊來完成。主要開發團隊在週末結束時會指示您在周五離開之前提交所有內容。當他們星期一回來時，一切都已遷移。

可悲的是，生活並不總是那麼輕鬆，對於這樣的理想情況，應用程式可能太大。在這種情況下，工作隊將與主要團隊同時在專門的migration部門工作超過乙個週末。但是他們需要與main分支保持最新，並且仍然保持工作。

因此，他們不時地將migration分支重新設定在master的頂部：

git rebase--onto master old-root-of-migration

這與合併不同，因為您使歷史記錄保持線性。

有時，出於多種原因，我想將更改保留在本地。例如，我可能會修改**質量工具的其他（或更嚴格的）規則。在這種情況下，我想花時間評估這是否與整個團隊相關。

如上所述，這是通過定期將我的本地tinker分支重新定為master。

如上所述，它使我可以保持歷史記錄的線性，並根據需要更改與tinker相關的提交。合併將阻止我執行此操作。

git rebase --onto可以有不同的用例。最重要的問題與長期分支（無論是本地分支還是遠端分支）的處理有關。

與往常一樣，它只是工具帶中的另乙個工具，因此並非所有事物看起來都像釘子一樣。

由於每個更改git歷史記錄的命令，git rebase --onto應該只更改本地提交。

您已被警告！

更進一步：

翻譯自: