当我使用了一点源代码后，我做了我通常的事情提交，然后推送到远程存储库。但后来我注意到我忘记在源代码中组织导入。因此，我执行modify命令以替换先前的commit：
> git commit --amend
不幸的是，无法将提交推回到存储库。它是这样被拒绝的：
> git push origin
To //my.remote.repo.com/stuff.git/
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to '//my.remote.repo.com/stuff.git/'
我该怎么办？（我可以访问远程存储库。）
当前回答
如果要更改的消息是针对存储库的最新提交，则将执行以下命令：
git commit --amend -m "New message"
git push --force repository-name branch-name
注意：除非您确信在最近一次提交后没有其他人克隆过您的存储库，否则不建议使用--force。
更安全的选择是使用：
git push --force-with-lease repository-name branch-name
与-force不同，-force将销毁其他人推送到分支的任何更改，如果存储库有上游更改，-forcewithlease将中止。
其他回答
简言之：不要将修改后的承诺推至公开回购。
长篇大论：一些Git命令，比如gitcommit--modify和gitrebase，实际上重写了历史图。只要你还没有发布你的更改，这是很好的，但一旦你发布了，你就真的不应该玩弄历史，因为如果有人已经得到了你的更改的话，那么当他们再次尝试时，可能会失败。您不应该修改提交，而应该使用更改进行新的提交。
但是，如果您真的、真的想推动修改的提交，可以这样做：
$ git push origin +master:master
前导+符号将迫使推送发生，即使它不会导致“快进”提交。（当您推送的更改是公共回购中已存在更改的直接后代时，会发生快速提交。）
如果您还没有将代码推送到远程分支（GitHub/Bitbucket），可以在命令行上更改提交消息，如下所示。
git commit --amend -m "Your new message"
如果您正在处理特定分支，请执行以下操作：
git commit --amend -m "BRANCH-NAME: new message"
如果您已经用错误的消息推送了代码，那么在更改消息时需要小心。即，在您更改提交消息并再次尝试推送后，您最终会遇到问题。要使其平滑，请执行以下步骤。
请在做之前阅读整个答案
git commit --amend -m "BRANCH-NAME : your new message"
git push -f origin BRANCH-NAME # Not a best practice. Read below why?
重要提示：当您直接使用强制推送时，您可能会遇到其他开发人员正在同一分支上工作的代码问题。因此，为了避免这些冲突，您需要在强制推送之前从分支中提取代码：
git commit --amend -m "BRANCH-NAME : your new message"
git pull origin BRANCH-NAME
git push -f origin BRANCH-NAME
如果提交消息已经被推送，这是更改提交消息时的最佳做法。
我必须通过从远程回购中提取来解决这个问题，并处理出现的合并冲突，提交然后推送。但我觉得还有更好的方法。
快速咆哮：没有人在这里发布简单的答案，这表明了Git CLI显示出的绝望的用户敌意。
无论如何，如果你没有试图强行推动，那么“显而易见”的方法就是先拉动。这将拉动您修改的更改（因此不再具有），以便您再次拥有它。
一旦解决了任何冲突，就可以再次推送。
So:
git pull
如果在pull中出现错误，可能是本地存储库配置有问题（我在.git/config分支部分中有一个错误的ref）。
之后
git push
也许你会得到一个额外的承诺，主题讲述一个“琐碎的合并”。
我通过放弃本地修改的提交并在顶部添加新的更改来解决这个问题：
# Rewind to commit before conflicting
git reset --soft HEAD~1
# Pull the remote version
git pull
# Add the new commit on top
git add ...
git commit
git push
