Git 重定基可将一组提交从一个分支移动到另一个分支。我对这个过程的理解正确吗？

我有三个分支：

master

，

develope

，和

release

。在

release

之外，我分支了一个单独的分支，名为

my bug fix

这个分支有五个分支。我将其合并回

版本

，因此我基本上有以下内容：

现在我想通过

f

提交

b

，并将这些修复移到

developer

中。我不能直接合并，因为我不想引入

c

。所以我发现你基本上可以做到：

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

我抽象地理解这里发生的事情。我们创建一个指向commit

h

的新分支。然后，我们使用

develope

作为新的基础，从

d

的父提交开始（因此也包括

d

）

我不明白的是，这到底是怎么回事，我想知道，因为我不喜欢在不了解实际情况的情况下盲目地运行命令。这是我到目前为止的理解。当我们创建

my bug fix develop

时，我们最终得到以下结果：

这就是我感到困惑的地方。现在，当我们做

git-rebase--on develop d^

时，git是否将

my bug fix develop

的

头
设置为指向
b
（即
develop
开始的提交），然后重放从
d
到
h
的所有提交

我想我的主要问题是
git checkout-b我对developh的bug修复的重要性。如果我在没有指定
h
的情况下进行分支，并且我尝试将
git-rebase——改为development d^
，那么我会得到一些甚至不是来自错误修复的其他更改。为什么将新分支的起点设置为
h
可以实现这一点

这是我认为正在发生的事情，我想知道我是对的还是偏离了底线。它找到了
mybug fixdevelope
和
develope
的共同祖先，即
a
。然后它从
MyBug fix develop
上的每个提交中获取所有差异。这将包括
d
到
h
，因为我指定从
d^
开始。然后它重置当前分支（
MyBugFixDevelop
）以指向
develop
（我正在重定的分支），然后在上面播放所有提交（
d
到
h
）

这就是正在发生的事情吗
 
git-rebase
将是实现这一点的一种方法，但我想我会推荐
git-cherry-pick
：

git checkout develop
git cherry-pick c..h

主要区别在于，
git cherry pick
不会移动您的
my bug fix
和
my bug fix develope
refs-它只会通过
h
提交
develope
中所做更改集的副本来推进
develope

但是，如果您希望在
develope
上使用side分支和merge commit，使其看起来有点像原始分支，那么请执行以下操作：

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

我对你们的图表有点困惑，因为它们的排序方式似乎有点不一致。箭头是否表示提交父级？还是要孩子？如果它们表示父级，则
my bug fix
只包含一个提交，而该提交不在
release
中，
d
，并且
i
-
e
无法从任何分支访问。若它们表示子对象，那个么develope已经合并到master中，并且并没有父对象，那个么您的重基示例的行为将和您期望的完全不同。我很困惑…@Ajedi32箭头表示父母。我标记的分支只是指向单个提交的指针。我现在才意识到我把图片弄糟了，因为我的bug补丁也应该指向
h
。我会换照片的。好的，谢谢。现在这就更有意义了。我以前肯定用过樱桃采摘。我只是好奇在这种情况下，重定基调是如何工作的。在这种情况下，重定基调的工作原理与樱桃采摘一样，在完成后，再加上移动分支参考点的步骤……啊，好的。那么，它的行为与rebase通常的行为类似？在
a
找到共同祖先，然后将新分支设置为指向
b
，然后通过
h
在其上播放
d
？@vivinvaliath在这种情况下，它不会找到
develop
和
my bug fix develop
的“共同祖先”，但是
d^
和
我的bug修复出现了
。关于rebase，请参见此格式的文档：（
git-rebase--on
）当然了。这是有道理的。非常感谢你！