为什么当我检查最近的提交时 Git 会撤消 rebase 过程？

亲爱的

我想删除 git repo 上的一个非常旧的提交，但是在执行 rebase 过程并签出到我的存储库的最后一个分支后，过程正在被撤消。所以，这就是我正在做的：

git log
abcdef - Last repo commit (master)
...
... # many many commits
...
222333 - A
111222 - B <-- I want to delete this
000111 - C

更改 HEAD，只是为了可读性：

git checkout 222333
git rebase -i 000111

此时，我编辑了 rebase 显示的待办事项，将文本从选择更改为编辑。

pick 222333 - A
pick 111222 - B (change to edit)
pick 000111 - C

现在我正在对提交中的文件内容进行修改。之后：

git add .
git commit --amend
git rebase --continue

毕竟，使用 git log 或 gitk 检查时一切正常。但是当我回到主 git checkout master 时，再次检查时，所有过程都被撤消了！有谁知道为什么？

环境：

问题是这一行，你说你这样做“只是为了可读性”：

git checkout 222333

这使您处于“分离头”状态：您的工作副本位于该修订版上，而不是任何分支。

在这种状态下，您对一些提交进行了重新设置，这会创建由新提交组成的新历史记录。通常，这也会移动当前分支指针以指向那些新提交，但是您没有当前分支，因此不会移动任何指针。

最后，您运行 git checkout master，它会切换到名为“master”的分支。一个分支只是一个指针，它并不指向 git rebase 生成的新提交，它指向它之前指向的任何地方。新创建的提交是“孤立的”，没有分支指向它们。

还有另一个问题：git 中的提交不可变，因此对历史的任何编辑都必须从那时起创建新的提交。您在日志摘要中显示的“许多提交”都需要重写，因此它们都需要列在交互式 rebase 待办事项列表中。

（如果你看过足够多的科幻电影，git中的“改变历史”就像时间旅行的形式，你不改变自己的过去，你创造了一个有着不同过去的平行宇宙，相应不同的未来。）

所以忘记让它“可读”，然后运行这个：

git checkout master
git rebase -i 000111

所有标记为“pick”的行都是将要重新创建的行；只需滚动它们并删除您想要不重新创建的那个。