如果您还没有推送提交，则可以使用git reset HEAD^[1,2,3,4…]返回到上一次提交

例如

git commit <file1> -m "Updated files 1 and 2"
git commit <file3> -m "Updated file 3"

抱歉，忘记在第一次提交时添加file2。。。

git reset HEAD^1 // because I only need to go back 1 commit

git add <file2>

这将在第一次提交时添加file2。

要获得非交互式命令，请在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＞。当然，如果您遇到冲突，它仍然是交互式的。

如果您还没有推送提交，则可以使用git reset HEAD^[1,2,3,4…]返回到上一次提交

例如

git commit <file1> -m "Updated files 1 and 2"
git commit <file3> -m "Updated file 3"

抱歉，忘记在第一次提交时添加file2。。。

git reset HEAD^1 // because I only need to go back 1 commit

git add <file2>

这将在第一次提交时添加file2。

更改上次提交：

git commit --amend
// or
git commit --amend -m "an updated commit message"

不修改公共承诺修改后的提交实际上是全新的提交，以前的提交将不再位于当前分支上。

例如，如果您想更改最后三个提交消息或该组中的任何一个提交消息，您可以向git rebase-i提供一个参数，该参数是您要编辑的最后一个提交的父级，即HEAD~2^或HEAD~3。记住~3可能更容易，因为您正在尝试编辑最后三次提交，但请记住，您实际上是在指定四次提交之前，即您要编辑的最后一次提交的父级：

$ git rebase -i HEAD~3

了解更多信息

我解决了这个问题，

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是不可接受的方法这棵树最终会陷入你们知道其他人不会发生的冲突。如果你愿意为了用更少的提交来保持树的整洁，可以尝试这样做，如果小团队，否则不可取。。。。。

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

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

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

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

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

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

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

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