首先，不要在main分支被推送后对其进行变基。引用git documentation on rewriting history的话（这是一种委婉的说法）：
Git的基本规则之一是，由于大量工作都在克隆中本地完成，因此您有很大的自由来 * 本地 * 重写历史。然而，一旦您推送了工作，情况就完全不同了，除非您有充分的理由更改它，否则您应该将推送的工作视为最终结果。简而言之，你应该避免推动你的工作，直到你对它感到满意，并准备与世界其他地方分享它。
举个例子，我正要帮助你，但是你把你的提交吹走了，现在我再也看不到它们了，只能猜测出了什么问题。变基是针对本地更改的。一旦你推送了一个分支，你就不应该变基它。这对你的主分支来说尤其如此。
你有几个问题。首先，你用HEAD~3指定上游的方式。这指向HEAD的第一个父节点。需要记住的几件事：

• 合并提交有多个父提交，并且你的历史中有一个合并提交。
• Git并不总是（甚至通常）以parent->child的顺序呈现提交。默认情况下，它是基于日期的，因此提交顺序的呈现方式与parent->child的顺序大不相同是很常见的。

所以，也许你现在可以看到HEAD~N的语法并不像看起来那么简单。当你查看提交列表时，你可能会认为HEAD~3意味着第三次提交，但情况并不总是这样（尽管它经常如此）。
最好更精确地指定上游。你想从你试图改写的提交的父提交开始变基。所以，从你想改写的提交复制哈希，然后通过在末尾添加一个插入符号来获得它的父提交。例如，ab123cde^

$ git rebase ab123cde^ -i

字符串
你的第二个问题是，你正试图对一个包含合并提交的分支进行变基。如果你正在变基的分支包含一个合并提交，你几乎总是会丢失那个合并提交，最后只会得到你指定的新顺序的单个提交。由于你没有预料到这一点，这是一个额外的复杂性，并且可以理解地令人困惑。与其只是改写一个提交并继续前进，你必须完全撤销并重做合并，再次解决所有的冲突，这次是一次一个提交，而不是一次解决所有的冲突。这可能比你希望的要复杂得多，当你想做的只是修复提交消息中的一个错字时，但这就是git的现实。
但是，说真的，一旦main分支被推送，就不要重定基它。