一个更简单的解决方案是git rebase <SHA1 of B> topic。不管你的头在哪里，这都是有效的。

我们可以从git rebase文档中确认这种行为

<upstream>要比较的上游分支。可能是任何有效的 提交，而不仅仅是一个现有的分支名称。默认为配置的 当前分支的上游。

你可能会想，如果我在上面的命令中也提到topic的SHA1会发生什么?

git rebase <SHA1 of B> <SHA1 from topic>

这也可以工作，但rebase不会使Topic指向这样创建的新分支，HEAD将处于分离状态。因此，从这里开始，您必须手动删除旧的Topic，并在rebase创建的新分支上创建一个新的分支引用。

如果您希望返回到不止一次提交，还有另一种方法。

下面是一个返回到n次提交的例子:

git branch topic master~n

为了解决这个问题，还可以这样做:

git branch topic master~1

该命令在git 2.7.4版本上运行良好。还没在其他版本上测试过。

你甚至可以采取直接的方法:

git checkout topic
git rebase <commitB>

上面jsz的注释为我节省了大量的痛苦，所以这里有一个基于它的逐步接收人，我一直在使用它来将任何提交重置/移动到任何其他提交之上:

找到要重基(移动)的分支的先前分支点-称其为旧父结点。在上面的例子中是A 找到你想要移动的分支的上面的提交-称为新父。在这个例子中是B 你需要在你的分支上(你移动的那个分支): 应用你的rebase: git rebase—到<new parent> <old parent>

在上面的例子中，这很简单:

   git checkout topic
   git rebase --onto B A

使用"onto"选项:

git rebase --onto master^ D^ D

OR

git rebase --onto <commitB> <commitA> <commitD>

最后3个参数的意思是: destination (new-parent，这里是commitB) Start-after (current-parent，第一个提交被移动的父节点)， 和end-inclusive(要移动的最后一个提交)。

一个更简单的解决方案是git rebase <SHA1 of B> topic。不管你的头在哪里，这都是有效的。

我们可以从git rebase文档中确认这种行为

<upstream>要比较的上游分支。可能是任何有效的 提交，而不仅仅是一个现有的分支名称。默认为配置的 当前分支的上游。

你可能会想，如果我在上面的命令中也提到topic的SHA1会发生什么?

git rebase <SHA1 of B> <SHA1 from topic>

这也可以工作，但rebase不会使Topic指向这样创建的新分支，HEAD将处于分离状态。因此，从这里开始，您必须手动删除旧的Topic，并在rebase创建的新分支上创建一个新的分支引用。