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

git checkout topic
git rebase <commitB>

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

实际上，使用commit (<commitD>)作为最后一个参数，而不是分支名称(topic)，应该创建一个分离的分支:

    A --- B --- C          master
     \     \
      \     -- D'          <detached HEAD>
       \
        \-- D             topic

除了……在Git 2.36之前，在某些情况下不会:

"git rebase $base $non_branch_commit"(man)，当$base是一个祖先或$non_branch_commit时，修改了当前的分支，这已在git 2.36 (Q2 2022)中更正。

参见John Cai (John - Cai)的commit bdff97a, commit 77ab58c (18 Mar 2022)。 (由Junio C Hamano - gitster -在提交f818536, 2022年3月29日合并)

rebase:在checkout_up_to_date()中设置REF_HEAD_DETACH 报道:Michael McClimon 签字人:John Cai

"git rebase A B"(man) where B is not a commit should behave as if the HEAD got detached at B and then the detached HEAD got rebased on top of A. A bug however overwrites the current branch to point at B, when B is a descendant of A (i.e. the rebase ends up being a fast-forward). See this thread for the original bug report. The callstack from checkout_up_to_date() is the following: cmd_rebase() -> checkout_up_to_date() -> reset_head() -> update_refs() -> update_ref() When B is not a valid branch but an oid, rebase sets the head_name of rebase_options to NULL. This value gets passed down this call chain through the branch member of reset_head_opts also getting set to NULL all the way to update_refs(). Then update_refs() checks ropts.branch to decide whether or not to switch branches. If ropts.branch is NULL, it calls update_ref() to update HEAD. At this point however, from rebase's point of view, we want a detached HEAD. But, since checkout_up_to_date() does not set the RESET_HEAD_DETACH flag, the update_ref() call will deference HEAD and update the branch its pointing to. We want the HEAD detached at B instead. Fix this bug by adding the RESET_HEAD_DETACH flag in checkout_up_to_date if B is not a valid branch, so that once reset_head() calls update_refs(), it calls update_ref() with REF_NO_DEREF which updates HEAD directly intead of deferencing it and updating the branch that HEAD points to.

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

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

git branch topic master~n

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

git branch topic master~1

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

我使用了上述解决方案的混合:

$ git branch temp <specific sha1>
$ git rebase --onto temp master topic
$ git branch -d temp

我发现它更容易阅读和理解。接受的解决方案导致我的合并冲突(懒得手动修复):

$ git rebase temp
First, rewinding head to replay your work on top of it...
Applying: <git comment>
Using index info to reconstruct a base tree...
M       pom.xml
.git/rebase-apply/patch:10: trailing whitespace.
    <some code>
.git/rebase-apply/patch:17: trailing whitespace.
        <some other code>
warning: 2 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
error: Failed to merge in the changes.
Patch failed at 0001 <git comment>
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

既然调整基地是如此重要，下面是内斯特·米利耶夫(Nestor Milyaev)答案的扩展。结合jsz和Adam Dymitruk回答中的Simon South的评论，得到了这个命令，无论它是从主分支的提交A还是C中分支，它都可以在topic分支上工作:

git checkout topic
git rebase --onto <commit-B> <pre-rebase-A-or-post-rebase-C-or-base-branch-name>

注意，最后一个参数是必需的(否则它会倒带分支以提交B)。

例子:

# if topic branches from master commit A:
git checkout topic
git rebase --onto <commit-B> <commit-A>

# if topic branches from master commit C:
git checkout topic
git rebase --onto <commit-B> <commit-C>

# regardless of whether topic branches from master commit A or C:
git checkout topic
git rebase --onto <commit-B> master

最后一个命令是我通常使用的命令。

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

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

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

   git checkout topic
   git rebase --onto B A