最安全快捷的方式是立即使用git commit --amend修改最近一次提交信息，前提是尚未推送到远程分支；操作可通过webstorm界面或快捷键触发，仅改message时默认不改动代码内容。
Commit后立刻修改提交信息（amend）
刚提交完发现 commit message 写错了、漏了 Jira ID 或拼写错误，最安全快捷的方式就是立刻 amend——前提是还没 push 到远程分支。
操作路径：右下角 Git 工具栏 → 点击 Commit 按钮旁的小箭头 → 选 Amend last commit；或者用快捷键 Ctrl+Shift+K（Windows/Linux）或 Cmd+Shift+K（macOS），此时会自动打开上次提交的编辑框。
- 只改 message 不动代码：勾选
Amend commit without changing commit content（默认勾选），改完直接Commit - 如果顺手改了代码又想一并塞进上一次提交：取消勾选该选项，再点
Commit，WebStorm 会把暂存区（Staged）内容合并进上一次 commit - 注意：一旦
push过，再 amend 就必须强制推送（git push --force-with-lease），协作中需谨慎
已 push 后想改最近一条提交信息
这不是 WebStorm 能“一键解决”的场景。WebStorm 的 Amend 功能在 push 后仍可触发，但底层执行的是 git commit --amend，之后你必然遇到 rejected non-fast-forward 错误，因为远程分支已存在旧 commit。
此时必须手动处理：
- 确认没人基于该 commit 继续开发（尤其是共享分支如
main） - 在 WebStorm 中完成 amend 后，右键 Git 仓库 →
Git Bash（或终端），运行：git push --force-with-lease origin <branch-name></branch-name> - 不要用
--force，--force-with-lease更安全，能防止覆盖他人新提交 - 如果团队用 protected branch（如 GitHub/GitLab 的 main 保护规则），强制推送会被拒绝，只能联系管理员临时解除保护或走 PR 流程
修改更早的提交信息（rebase -i）
WebStorm 不提供图形化交互式变基界面，但支持调用命令行完成 git rebase -i，适合改倒数第 2 条、第 5 条等非最新提交的 message。
GitHub 项目更新追踪工具 - 自动检查多个 GitHub 项目的 Releases 和 CHANGELOG，生成更新摘要与影响分析报告。支持自动化定时任务。 如何使用 最简单的方式：直接用自然语言告诉我 你可以说 我会做 「检查 GitHub 更新」 检查最新版本 「添加 vscode」 追踪新项目 「停止追踪 xxx」 移除项目 「暂停更新检查」 暂停自动化 「给我看 openclaw 报告」 展示报告 触发词：「追踪项目更新」「检查 GitHub 更新」「项目更新报告」「设置更新提醒」
步骤：
- 打开 Terminal（
Alt+F12），运行：git rebase -i HEAD~3（想改最近 3 次中的某条，就填 3） - 编辑器弹出列表，默认是
pick，把要改的那行开头改成reword（不是edit，后者会停在那让你改代码） - 保存退出，Git 会逐个打开对应 commit 的编辑器让你改 message
- 改完保存，rebase 自动继续；若中途出错，按提示运行
git rebase --continue或--abort - 完成后仍需
push --force-with-lease（如果已推过）
注意：reword 只改 message，不碰代码；但整个 rebase 过程会重放所有提交，SHA-1 值全变，历史被重写。
为什么不能直接编辑 .git/COMMIT_EDITMSG？
有人尝试手动改 .git/COMMIT_EDITMSG 文件，以为能覆盖上次 message——没用。这个文件只是 git commit 命令启动时的临时输入缓冲，和实际 commit 对象无关。真正存储 message 的是 commit 对象本身（在 .git/objects/ 里），只能靠 --amend 或 rebase 生成新对象来替换。
WebStorm 的 Commit 窗口里改完不点 Commit，只关掉窗口，也不会生效；它不会偷偷保存草稿。message 修改只有在明确触发 commit/amend 动作后才写入 Git 数据库。
最容易被忽略的一点：amend 后的 commit 时间戳会更新为当前时间，而不是原提交时间——如果项目审计依赖精确时间线，这点得提前对齐团队认知。
