我对文件进行了一些更改，并使用描述性提交消息提交它，并将其推送到源。几秒钟后，我发现同一个文件中存在拼写错误并修复了它。我决定修改最后一次提交而不是添加新的提交，因为我不喜欢用无关的提交污染我的历史记录。
不幸的是，再次推送它会导致上游发生冲突，因为我本地修改后的提交与我刚刚推送的提交不一致。我不明白如何合并。即使我确实知道如何做，想必它会创建另一个不必要的合并提交。
上次发生这种情况时，我通过强制推送解决了它，这在团队环境中是不受欢迎的。奇怪的是，当使用看似无害的
--amend我如何以礼貌和干净的方式解决这个冲突。另外，下次修改已经推送的提交时该怎么办？
如果您正在开发一个功能分支，尤其是尚未作为 PR 提交的分支，则该分支（在所有合理的工作流程下）完全属于您。它不构成共享材料。如果你用力推动，没有人会知道或关心。
所以，假设发生的事情是这样的：
git branch myFeature
# edit, add, commit... edit, add, commit...
git push origin myFeature
git commit --amend
...说的很有道理
git push --force origin myFeature
这是一种“礼貌而干净的方式”来重塑这个功能分支的历史，只有你正在处理这个分支，因此它完全属于你。但这不一定是您能做的最礼貌和最干净的事情。继续阅读...
奇怪的是，当使用看似无害的
提交选项时，Git 没有给出任何警告。--amend
不，不是。如果你知道 Git 是什么，那就不会了。 Git 是一个commits 的有向图（每个提交至少有一个父提交）。一旦创建，提交就“完全不可变”。不存在编辑提交这样的事情。这是一条必要的规则，因为否则 Git 将无法完成其工作，即“保存历史记录”。 因此，使用 Git 的简单直接方法就是“继续前进”。做出更多承诺！如果您推送了一次提交，然后发现其中一个文件有错误，请修复错误，添加并提交！新的提交修复了旧提交中的错误，项目的整体状态得到了改善。现在推送，将您的提交保存到服务器。服务器只是将其添加到该分支现有历史记录的顶端。 当你说
--amend时，另一方面，你是在提议改变历史。您不能重写现有的提交；您正在历史记录中旧提交所在的位置进行“全新”提交。如果您已经推送了旧的提交，那么现在您和服务器之间的历史记录存在根本性的“分歧”；你说某个提交进入历史记录中的某个“槽”，服务器说“不同的”提交进入该槽。这是一个不可调和的差异，所以你必须用
force来推动。
所以，总而言之，以下是您的选择： 继续前进。编辑、添加、提交、推送，一遍又一遍。另一方面，如果您觉得可能想要重写功能分支内的历史记录，那么不要推送它。只需在分支上工作，直到它准备好，然后
推动它。
或者，接受这样一个事实：如果您
do然后重写其历史记录，则必须使用force才能下次推送它。