變基以將一組提交從一個分支移到另一個分支。 我對這個過程的理解正確嗎？

Question

我有三個分支： master ， develop和release 。 release ，我分支了一個名為my-bug-fix的單獨分支。

該分支有五個提交。 我將其合並回了release ，所以基本上有了：

現在，我要從b到f進行提交，並將這些修訂移入develop 。 我不能直接合並，因為我不想引入c 。 所以我發現您基本上可以做到這一點：

git checkout -b my-bug-fix-for-develop h
git rebase --onto develop d^
git checkout develop
git merge my-bug-fix-develop

我從抽象的角度了解這里發生了什么。 我們創建一個指向提交h的新分支。 然后，我們用重訂， develop作為新的基地，從父開始提交的d （這樣將包括d為well`）。

我不了解的是它如何實際發揮作用，我很想這樣做，因為我不想在不真正了解正在發生的情況的情況下盲目運行命令。 到目前為止，這是我的理解。 創建my-bug-fix-develop ，我們最終得到以下結果：

這就是我感到困惑的地方。 現在，當我們執行git rebase --onto develop d^ ，git首先將my-bug-fix-develop的HEAD設置為指向b （即， develop開始的提交）， 然后重播d之前的所有提交直到h ？

我想我的主要問題是git checkout -b my-bug-fix-for-develop h的重要性。 如果我在未指定h情況下分支，而我嘗試執行git rebase --onto develop d^ ，那么我將得到一些其他更改，這些更改甚至都不來自該錯誤修正。 為什么將新分支的起點設置為h可以使此項工作？

我想這就是正在發生的事情，我想知道我是對的還是偏離基礎的。 它發現的共同祖先my-bug-fix-develop和develop ，這是a 。 然后，它從my-bug-fix-develop上的每個提交獲取所有差異。 自從我指定從d^開始以來，這將包括d到h 。 然后，它將當前分支（ my-bug-fix-develop ）重置為指向develop （我要重新部署到的分支），然后在其上面播放所有這些提交（ d到h ）。

這是怎么回事嗎？

Answer 1

git rebase將是執行此操作的一種方法，但是我認為我建議使用git cherry-pick代替：

git checkout develop
git cherry-pick c..h

主要區別在於git cherry-pick不會移動您的my-bug-fix和my-bug-fix-develop引用-它將使用新的提交（即通過d提交的更改集的副本）進行develop h 。

但是，如果您希望在develop上具有側分支和合並提交，以使其看起來有點像原始分支，則可以這樣做：

git checkout -b develop-bug-fix develop
git cherry-pick c..h
git checkout develop
git merge --no-ff develop-bug-fix