我觉得这个问题已经被问了很多次，但通常的解决方案是“删除目录并使用全新的checkout重新做一遍工作。” 我进行了提交和推送，但后来意识到在提交消息中引用了错误的票据编号。 因此，我在SO上寻找了一个快速的解决方案，最终在终端中输入了以下内容:
$ git reset --soft HEAD^
$ git commit -m "... correct message ..."
唯一的问题是我收到了以下错误消息：
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
git reset, git rebase, git filter-branch或任何其他历史操作），然后将重写的提交推回服务器，那么任何已经拉取了该提交的人都会出现问题。这里有一个例子：假设你已经提交了A，并将其推送到服务器。
-*-*-A <-- 主分支现在你决定按照上述方式重写A，重置并重新提交。请注意，这会留下一个悬空的提交A，因为它是不可达的，最终将被垃圾回收。
-*-*-A <-- 远程主分支
-*-*-A
\
A' <-- 主分支
-*-*-A <-- 远程主分支
如果有其他人（比如Fred）在你这样做时从服务器上拉取了主分支，他们将拥有对A的引用，可能会从A开始工作：
-*-*-A' <-- 主分支现在，如果你能够将A'推送到远程主分支，这将创建一个非快进式的提交，它的历史记录中没有A。因此，如果Fred再次尝试拉取，他将突然不得不合并，并重新引入A提交：
-*-*-A <-- 远程主分支
-*-*-A-B <-- Fred/主分支
-*-*-A' <-- master
-*-*-A <-- origin/master
-*-*-A-B-\
\ * <-- fred/master
A'--/
如果Fred注意到这个问题，他可以进行一次变基(rebase)，这将防止提交A再次出现。但他必须注意到这个问题，并记得这样做；如果有不止一个人拉取了提交A，那么他们都必须变基才能避免在树中获得额外的A提交。
因此，在拉取其他人的仓库时，通常不建议更改历史记录。但是，如果您知道没有其他人从该仓库拉取（例如，它是私有的仓库或者只有一个开发人员正在协调易于协调的项目），那么您可以通过运行以下命令强制更新：
git push -f
或者
git push origin +master
receive.denyNonFastForwards配置选项完全禁用了强制推送。该选项在共享存储库上默认启用。在这种情况下，如果你真的想强制推送，最好的选择是删除分支并重新创建它，使用git push origin :master; git push origin master:master。但是，denyNonFastForwards选项有其原因，如上所述；在共享存储库上，这意味着现在每个使用它的人都需要确保他们重新基于新历史记录。git revert生成撤消先前提交更改的提交。git push --force。 - Bennett McElweereceive.denyNonFastForwards来完全禁用强制推送，这将防止在共享仓库上进行此类操作。如果你确实需要强制推送，最好的方法是删除分支并重新创建它，使用命令git push origin :remote_A; git push origin local_A:remote_A。但请注意，在共享仓库上执行此类工作流程可能会带来问题，请先仔细阅读我之前所写的内容。你应该只在需要消除或重写提交中存在严重问题时尝试这样做。 - Brian Campbell强制执行git push:
git push origin +develop
你可能需要执行git pull命令，它可能会自动为你合并内容，然后你就可以再次提交。如果有冲突，它会提示你解决冲突。
请记住，如果你没有更新gitconfig指定哪个分支进行拉取，你必须指定要从哪个分支进行拉取...
例如：
git pull origin develop:develop
! [rejected] develop -> develop (non-fast-forward) - rynmrtngit push origin develop，它仍然显示之前的提交为最新）。 - rynmrtn我曾经在使用EGit时也遇到了这个问题。只需要尝试 rebase 当前分支即可解决。