基于文档

修改旧的或多个提交消息的消息

git rebase -i HEAD~3 

上面显示了当前分支上最后3次提交的列表，如果需要更多，请将3更改为其他内容。列表将类似于以下内容：

pick e499d89 Delete CNAME
pick 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.

将pick替换为要更改的每个提交消息之前的改写。假设您更改了列表中的第二个提交，您的文件将如下所示：

pick e499d89 Delete CNAME
reword 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.

保存并关闭提交列表文件，这将弹出一个新的编辑器，供您更改提交消息、更改提交消息并保存。

最后，强制推行修改后的承诺。

git push --force

嗯，这个解决方案可能听起来很愚蠢，但在某些情况下可以拯救你。

我的一个朋友刚刚无意中提交了一些非常大的文件（四个自动生成的文件，每个文件的大小在3GB到5GB之间），然后在此基础上提交了一些额外的代码，然后才意识到git推送不再有效的问题！

这些文件已在.gitignore中列出，但在重命名容器文件夹后，它们被暴露并提交了！现在，在上面还有几次代码提交，但推送一直在运行（试图上传GB的数据！），最终由于Github的文件大小限制而失败。

交互式rebase或任何类似的问题是，他们会处理这些巨大的文件，并且会花费很长时间来做任何事情。然而，在CLI中花了将近一个小时后，我们不确定文件（和增量）是否真的从历史中删除了，或者只是不包括在当前提交中。推也不起作用，我的朋友真的卡住了。

因此，我提出的解决方案是：

将当前git文件夹重命名为~/Project old。再次从github克隆git文件夹（到~/Project）。签出到同一分支。手动将文件从~/Project旧文件夹cp-r到~/Project。确保不需要签入的大量文件被mved并正确包含在.gitignore中。还要确保您没有用旧文件夹覆盖最近克隆的~/Project中的.git文件夹。这就是有问题的历史记录的所在！现在查看更改。它应该是所有最近提交的联合，不包括有问题的文件。最后提交更改，这很好。

这个解决方案最大的问题是，它处理手动复制一些文件，并且它将所有最近的提交合并为一个（显然使用了一个新的提交哈希）

最大的好处是，它在每一步中都非常清晰，它适用于大型文件（以及敏感文件），并且不会在历史上留下任何痕迹！

我解决了这个问题，

1） 通过使用我想要的更改创建新的提交。。

r8gs4r commit 0

2） 我知道我需要合并哪个提交，即提交3。

因此，gitrebase-i HEAD~4#4表示最近的4次提交（此处提交3位于第4位）

3） 在交互式rebase中，最近的提交将位于底部。它看起来很像，

pick q6ade6 commit 3
pick vr43de commit 2
pick ac123d commit 1
pick r8gs4r commit 0

4） 如果您想与特定的提交合并，我们需要重新排列提交。应该是这样的，

parent
|_child

pick q6ade6 commit 3
f r8gs4r commit 0
pick vr43de commit 2
pick ac123d commit 1

重新排列后，需要将p pick替换为f（fixup将在没有提交消息的情况下进行合并）或s（带有提交消息的压缩合并可能在运行时发生变化）

然后保存你的树。

现在与现有提交合并完成。

注意：除非你自己维护，否则这不是更好的方法。如果你的团队规模很大，重写git是不可接受的方法这棵树最终会陷入你们知道其他人不会发生的冲突。如果你愿意为了用更少的提交来保持树的整洁，可以尝试这样做，如果小团队，否则不可取。。。。。

我执行以下操作，包括更改本地提交的日期和时间：

git rebase -i HEAD~6

~6是要显示的提交历史记录的数量。

从pick更改为编辑要编辑的提交。然后我保存并退出（在ubuntu中：Ctrl+O保存，Ctrl+X退出）然后我运行：gitcommit--modify--date=“2022-09-02TT1:10:04”-m“NEW_MSG”如果编辑已打开，只需保存并退出即可。然后，为了确认并转到下一个提交或完成（如果是最后一个），我执行：gitrebase--continue

如果有更多提交要编辑，则从第1点开始重复

最后，我验证更改，如果一切正常，我会推送

当我需要更深入地修复历史中以前的提交时，我经常使用交互式rebase和--autosquash。它本质上加快了ZelluX的回答所说明的过程，当您需要编辑多个提交时，它特别方便。

根据文档：

--自动撤销当提交日志消息以“squash…​“（或”修复…​“），并且有一个提交的标题以相同的开头…​, 自动修改rebase-i的todo列表，以便标记为挤压的提交在要修改的提交之后立即出现

假设您的历史记录如下：

$ git log --graph --oneline
* b42d293 Commit3
* e8adec4 Commit2
* faaf19f Commit1

并且您有要修改为Commit2的更改，然后使用

$ git commit -m "fixup! Commit2"

或者，您可以使用commit sha而不是commit消息，因此“fixup！e8adec4”或甚至只是commit消息的前缀。

然后在提交之前启动交互式重新基础

$ git rebase e8adec4^ -i --autosquash

编辑器将打开已正确排序的提交

pick e8adec4 Commit2
fixup 54e1a99 fixup! Commit2
pick b42d293 Commit3

你只需要保存并退出

完全非交互式命令（1）

我只是想分享一个我正在使用的别名。它基于非交互式交互式数据库。要将其添加到git中，请运行以下命令（解释如下）：

git config --global alias.amend-to '!f() { SHA=`git rev-parse "$1"`; git commit --fixup "$SHA" && GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^"; }; f'

或者，一个也可以处理未暂存文件的版本（通过先暂存，然后再卸载）：

git config --global alias.amend-to '!f() { SHA=`git rev-parse "$1"`; git stash -k && git commit --fixup "$SHA" && GIT_SEQUENCE_EDITOR=true git rebase --interactive --autosquash "$SHA^" && git stash pop; }; f'

这个命令的最大优点是它不是vim。

（1） 当然，考虑到重新启动期间没有冲突

用法

git amend-to <REV> # e.g.
git amend-to HEAD~1
git amend-to aaaa1111

将名称修改为似乎合适IMHO。将流程与--修订：

git add . && git commit --amend --no-edit
# vs
git add . && git amend-to <REV>

解释

git-config—全局别名<名称>'<COMMAND>'-创建名为<NAME>的全局git别名，该别名将执行非git命令<COMMAND>f（）｛＜BODY＞｝；f-一个“匿名”bash函数。SHA=`git rev parse“$1”`；-将参数转换为gitrevision，并将结果赋给变量SHAgitcommit--fixup“$SHA”--fixup提交SHA。参见git提交文档GIT_SEQUENCE_EDITOR=true GIT rebase--交互式--autosquash“$SHA^”gitrebase——交互式“$SHA^”部分已被其他答案覆盖。--autosquash与gitcommit一起使用--fixup，有关更多信息，请参阅gitrebase文档GIT_SEQUENCE_EDITOR=true是使整个事情非交互式的原因。这是我从这篇博客文章中学到的。