在回答问题之前，我应该先提醒一下：无论你如何编辑提交信息，都会涉及到在git中
重写历史。
这不是你应该对已经推送到其他人可能检出或建立的分支（例如master）的提交进行的操作。一旦你将提交推送到类似于主分支的分支上，你应该认为这些提交是永久/定稿的。除非你有一个非常好的理由（例如，你推送了一个包含某些安全敏感内容（例如你的私人ssh密钥）的提交），否则你不应该重写这个历史。
第二，这不会解决你的问题，但是假设
<commit_hash>是指你想要编辑的提交哈希值，
git rebase -i <commit_hash>是不正确的。正确的版本，在你提供的指令中已经给出，应该是
git rebase -i <commit_hash>^（注意末尾的
^）。Rebase不包括你传递的参数，所以如果你想编辑
<commit_hash>，你必须把它之前的那个提交传递给rebase（即
<commit_hash>^）。
正如@Sergio所提到的，这个问题的原因可能是最近3次提交中有一个合并提交。由于各种原因，rebase不太适合处理合并提交。
虽然重新设置合并提交并不是不可能的，但没有单一明确、合理的方法来完成它，因此有几种不同的选项来告诉git如何做。此外，在重新设置合并提交的过程中还有许多微妙的细节，如果您不熟悉git可能会有点难以解释。
如果您没有足够的知识从git文档中弄清楚如何做到这一点，我建议您使用更手动的等效方法：
- 在提交代码之前打标签，以防出现错误需要撤销或重新开始：使用
git tag temp。同时，检查一下是否有未暂存或未提交的更改，可以使用git status命令。
- 重置到你想要编辑消息的提交位置：使用
git reset --hard HEAD~3 命令。
- 使用
git commit --amend命令编辑提交消息。
- 重新创建其他更改，使它们建立在新的、已修改的提交上，并更新提交消息。对于非合并提交，可以使用cherry-pick命令将它们复制过来。对于合并提交，您需要像第一次创建它们时一样使用
git merge命令重新创建它们。如果有冲突，需要重新解决它们。如果合并包含了一些手动修改，你也需要重新进行这些修改。
- 使用
git diff temp和git range-diff HEAD...temp命令再次检查结果。如果不正确，或者在任何时候你意识到自己犯了一个错误，可以使用git reset --hard temp命令重新开始。
- 推送更改：
git push --force-with-lease（--force-with-lease是--force的更安全的替代方法）。
- 如果一切正常，现在可以删除标签：
git tag -d temp。
这基本上与
git rebase -i --rebase-merges=no-rebase-cousins 所做的事情是相同的，但是如果你对 git 还不熟悉，它会有更低的混淆或错误的潜力。
最后需要注意的是：如果您要编辑的提交是合并提交，并且之后没有其他合并提交，那么您还有另一种选项，可以避免重新设置合并提交的问题。而是只重新设置其后的提交，但在待办事项列表的开头（
pick <hash> message 行之前）插入一个断点。这样，您可以使用
git commit --amend 编辑合并提交，然后在重新应用提交之前重新启动重新设置时，它将在您新修改的合并提交之上重新应用提交。
n次提交中没有任何合并提交。 - Louis