要获得非交互式命令，请在PATH中放置包含以下内容的脚本：

#!/bin/sh
#
# git-fixup
# Use staged changes to modify a specified commit
set -e
cmt=$(git rev-parse $1)
git commit --fixup="$cmt"
GIT_EDITOR=true git rebase -i --autosquash "$cmt~1"

使用它，先暂存更改（使用gitadd），然后运行gitfixup＜commit to modify＞。当然，如果您遇到冲突，它仍然是交互式的。

如果出于某种原因，您不喜欢交互式编辑器，可以使用gitrebase--on。

假设您要修改Commit1。首先，从Commit1之前分支：

git checkout -b amending [commit before Commit1]

第二，用樱桃核抓取Commit1：

git cherry-pick Commit1

现在，修改您的更改，创建Commit1'：

git add ...
git commit --amend -m "new message for Commit1"

最后，在隐藏了任何其他更改后，将其余的提交移植到master之上新提交：

git rebase --onto amending Commit1 master

阅读：“将Commit1（不包括在内）和master（包括在内）之间的所有提交重新纳入修改分支”。即Commit2和Commit3，将旧的Commit1完全删除。你可以随便摘，但这样更容易。

记得清理你的树枝！

git branch -d amending

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

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

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

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

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

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

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

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

基于文档

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

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

Run:

$git rebase--交互式commit_hash^

每个^表示要编辑的提交次数，如果只有一个（指定的提交哈希），则只需添加一个^。

使用Vim，您可以更改要更改、保存和退出的提交的单词pick to reword（：wq）。然后git将提示您标记为reword的每个提交，以便您可以更改提交消息。

您必须保存并退出（：wq）以转到下一个提交消息的每个提交消息

如果要退出而不应用更改，请按：q！

编辑：要在vim中导航，请使用j向上，k向下，h向左，l向右（所有这些都在正常模式下，按ESC键转到正常模式）。要编辑文本，请按i以进入INSERT模式，在该模式下插入文本。按ESC返回正常模式：）

更新：这里有一个来自github的链接，列出了如何使用git撤消（几乎）任何操作

使用令人惊叹的交互式rebase：

git rebase -i @~9   # Show the last 9 commits in a text editor

找到所需的提交，将pick更改为e（编辑），然后保存并关闭文件。Git将返回到该提交，允许您：

使用gitcommit--修改以进行更改，或使用gitreset@~放弃最后一次提交，但不放弃对文件的更改（即，将您带到编辑文件但尚未提交的位置）。

后者对于执行更复杂的任务（如拆分为多个提交）非常有用。

然后，运行git-rebase--continue，git将在修改后的提交之上回放后续更改。可能会要求您修复一些合并冲突。

注意：@是HEAD的简写，~是指定提交之前的提交。

阅读Git文档中有关重写历史的更多信息。

不要害怕重新启动

ProTip公司™: 不要害怕尝试“危险”的命令来重写历史*-默认情况下，Git不会在90天内删除您的提交；你可以在reflog中找到它们：

$ git reset @~3   # go back 3 commits
$ git reflog
c4f708b HEAD@{0}: reset: moving to @~3
2c52489 HEAD@{1}: commit: more changes
4a5246d HEAD@{2}: commit: make important changes
e8571e4 HEAD@{3}: commit: make some changes
... earlier commits ...
$ git reset 2c52489
... and you're back where you started

*注意一些选项，比如硬和强制，它们可以丢弃数据。*此外，不要重写您正在合作的任何分支的历史。

在许多系统上，git-rebase-i将默认打开Vim。Vim不像大多数现代文本编辑器那样工作，所以看看如何使用Vim重新设置基础。如果您希望使用不同的编辑器，请使用git-config--global-core.editor或您最喜欢的文本编辑器对其进行更改。