正如其他答复和评论中所说：您只提供了部分信息，不足以确定您的问题。
这里有一个盲目的猜测：
如果你在混合中有 merge commits，你可能会遇到一些奇怪的事情，可能符合你所描述的：

• git log仍然会显示线性提交序列，这可能会让你相信你的 history 是线性的，
• HEAD~3（或~n）将指向比您认为的更晚的提交，
• git rebase的默认行为是从它重写的序列中完全删除合并提交

所以你可能会得到一个从比你预期的更早的提交开始的重定基准的历史。
一种可能性符合您的示例描述：
如果重定基后的历史记录实际上是：

* E
* D
* G
|\
| * F
|/
* C
* B
* A

然后

• HEAD~3实际上是C（不是F），
• git rebase -i HEAD~3将请求重放F D E的指令（G将被丢弃），
• 并且结果将是在C之上的线性历史。

一个建议：
当您想使用git log查看自己的历史记录时（与之相反：在脚本中使用git log的输出），always 添加--graph选项。这将允许您在历史记录中实际查看fork和merge。
查看我的回购历史记录的常用命令是：

git log --oneline --graph

另一个建议：
计算你的提交数（在正确的历史图上），或者使用分支名称而不是HEAD~n。
以你在问题中描述的例子为例：将D和E合并在一起只需要git rebase -i HEAD~2或git rebase -i master，这将在G之上创建一个提交。

您从未向我们展示您在启动交互式rebase后所采取的步骤，但如果您只想压缩前2个最近提交，您只需要：

# from feature branch
git rebase -i HEAD~2

这应该会带来一个编辑器，看起来像下面这样：

pick efgh456 message for commit D
pick abcd123 message for commit E

编辑此文件并更改为：

pick efgh456 message for commit D
squash abcd123 message for commit E

然后关闭/保存编辑器，这将启动变基。解决可能发生的任何合并冲突。现在你的历史应该看起来像：

master: A -- B -- C -- D -- E -- F -- G
                                       \
feature:                                DE (single squashed commit)

另一种替代蒂姆的方法可能只是合并和挤压…我通常是这样做的：

git checkout feature-branch
git merge main-branch
# assuming the merge was successful, if it's not successful, then
# you need to wrap it up and commit to continue.
git reset --soft main-branch
git commit -m "Here's a single commit for my feature"

如果它是一个短分支，我可能会重定基…如果它是一个更长的分支，我会走这条路。