改提交信息这事，操作命令就那么几个，真正麻烦的是知道改哪一条、影响哪些人。如果只是最新一条提交写错了，git commit --amend 能直接解决；但已经推送到远程的早期提交，改动一下就会牵动一整串哈希值。下面按处理顺序拆开说，重点放在“改之前怎么判断”和“推送后怎么确认”。

先判断改动落在哪一条提交

提交信息修改的时机决定使用哪种命令。如果错误只出现在最新一条提交上，直接执行 git commit --amend 最省事；若需要修改的是倒数第二条或更早的提交，就必须动用交互式变基。判断标准很简单：先用 git log --oneline 查看提交历史，确认目标提交与 HEAD 之间的距离，再决定操作方式。这个判断直接影响后续步骤的复杂度，也能避免误改无关提交。

实际操作时，我会把 git log --oneline 的输出扫一遍，找到那一行提交说明，记下它前面有几条提交。git rebase -i HEAD~n 里的 n，容易数错，建议按“从目标提交开始到 HEAD 为止一共有几条提交”来算。比如想改 HEAD~1，n 就填 2；想改 HEAD~2，n 就填 3。

本地改写：reword 而不是 edit

对于已推送的早期提交，推荐使用 git rebase -i 重写。具体做法是：先 git rebase -i HEAD~n，其中 n 为目标提交到当前分支顶部的提交数；把目标提交行的 pick 改为 reword，保存退出；随后编辑器会打开该提交的说明，修改并保存。这仅改变提交信息，不触碰文件内容。完成后本地提交历史已经更新，但远程仍保留旧版，需要强制推送才能同步。

这里要提醒的是，reword 和 edit 是两回事。reword 只改提交信息，改完直接继续；edit 则是让变基停在那个提交上，等你去改文件、改暂存区，最后还要 git rebase --continue。如果只是想修正拼写或补充说明，用 reword 就够了。把 pick 改成 edit，很容易在后续步骤被复杂的冲突提示卡住。

推送前先想清楚风险边界

重写已推送提交会改变所有后续提交的哈希值，任何基于旧历史的分支都会面临合并冲突。强制推送是高风险操作，尤其是共享分支。我一般会先 git fetch，确认远程没有新提交，再用 git push --force-with-lease 推送。force-with-lease 会检查远程分支是否还是你最后拉取的状态；如果期间有人推送过，它会拒绝执行，比直接 git push --force 安全得多。

如果 force-with-lease 报错，说明远端有其他人推了新提交。这时不要强推，应该先和协作者对齐：要么让同事把改动合并到新历史之上，要么放弃这次改写。共享分支上最忌“先推再说”，一旦覆盖，别人本地留着旧哈希，之后合并怎么难受都只能自己收尾。

推送后确认远端真正更新

推送完成后不能只看终端提示，要主动确认远程状态。执行 git log --oneline 查看本地提交信息，再用 git fetch 拉取远程引用，对比 origin/branch 与本地是否完全一致。对于协作者，可要求他们运行 git fetch 与 git log --oneline origin/branch 确认新的历史基线；若他们在重写前已有拉取的旧提交，需要 git reset --hard origin/branch 或基于新历史变基，而不是直接合并，以免把旧哈希重新带回来。

所谓“对比 origin/branch 与本地”，最直接的办法是分别执行 git log --oneline origin/branch 和 git log --oneline，看两边哈希是否一一对应。协作者那边，除非明确知道自己在做什么，否则不要用 git pull 直接合并旧历史。先 git fetch，再 reset 到新基线，是更干净的做法。

边界情况与回滚提醒

如果目标提交上打了 tag，变基不会更新 tag，tag 仍然指向旧哈希。光改分支历史不够，还要把旧 tag 删掉，重新在对应提交上打 tag。多人协作时，删除和重建 tag 会影响别人，需要提前喊一声。另一个情况是，有些人基于旧历史提交了新 commit，重写历史后合并时很容易把旧提交又带回来。如果提交已经扩散，建议放弃重写，改用新增提交来补充说明，而不是冒险强推。

本地做完 rebase 后，旧提交不会立刻从 reflog 消失。改到一半发现改错了，可以用 git reflog 找到操作前的哈希恢复。但一旦强制推送覆盖远程，远程的旧提交就可能找不回来。所以推送前再确认一次，推送后也别急着删 reflog。