git commit --amend 可修改最近一次提交的 message，默认保留文件变更、作者和时间戳，但会生成新 hash；加 -m 参数可跳过编辑器，若已 push 需 force push。
git commit --amend 怎么改最后一次提交的 message
直接运行 git commit --amend，它会打开默认编辑器，让你修改上一次提交的描述。保存退出后，commit 的 hash 会变（因为内容变了），但其他改动（文件变更、作者、时间戳）默认保留。
常见错误现象：git commit --amend 执行后没反应？其实是编辑器卡住了——你得手动输入新 message，保存并退出（比如 Vim 里按 :wq，Nano 里按 Ctrl+O → Enter → Ctrl+X）。
- 如果只想改 message 不进编辑器，加
-m参数：git commit --amend -m "新的描述" - 如果上一次提交已经 push 到远程，改完必须强制推送：
git push --force-with-lease origin main（别用--force，更安全） -
--amend只影响最近一次提交；想改更早的，得用git rebase -i
为什么改完 message 后 git log 显示两个一样的 commit？
这不是真的“两个 commit”，而是你看到的是旧 commit 和新 commit 的 hash 并存——说明你没成功 amend，或者 amend 后又做了新提交。典型原因是：执行了 git commit --amend，但编辑器里没改内容就直接保存退出了（Git 认为无变更，不生成新 commit）。
验证是否成功：执行 git log --oneline，看最新一条的 hash 是否和之前不同。如果一样，说明 amend 失败；如果变了，但旧 hash 还在 log 里，那是因为 Git 默认保留引用（比如 HEAD@{1}），可用 git reflog 查。
- amend 本质是“丢弃旧 commit，创建一个新 commit”，所以 hash 必然变化
- 本地分支指针会自动指向新 commit；远程分支不会同步，需显式 force push
- 如果团队协作中已有人基于原 commit 继续开发，force push 会导致他们 fetch 后出现分叉，需提前沟通
git commit --amend 会连带修改哪些字段？
默认只改 message，但可以一并覆盖 author、date、甚至暂存区内容。关键看加什么参数：
- 改 author：
git commit --amend --author="Name <email>"</email> - 重设 commit 时间为当前时间：
git commit --amend --date=now - 把暂存区新改动也塞进这次 commit：
git add file.txt && git commit --amend - 清空暂存区再 amend（只改 message）：
git reset HEAD && git commit --amend
注意：--date 和 --author 修改后，Git 会重新计算 commit hash，且这些字段一旦 push 过，再改就会触发 force push 需求。
rebase -i 和 --amend 选哪个？
只改最近一次 message，用 --amend；要改倒数第 2 次、合并多个 commit、或调整顺序，必须用 git rebase -i HEAD~3 这类交互式变基。
容易踩的坑：误以为 --amend 能改任意 commit —— 它只能作用于 HEAD，背后没有“历史编辑器”逻辑。而 rebase -i 是真正在重放提交，风险更高，尤其涉及已推送的提交时，冲突和引用混乱概率大增。
-
--amend是轻量、瞬时、单点修正 -
rebase -i是重写一段历史，适合本地未共享的提交流 - 哪怕只是改倒数第二次的 message，也得进 rebase，不能靠两次 amend 解决
真正难的不是命令怎么敲，而是判断“这个 commit 还有没有被别人基于它工作”。只要不确定，就别 force push —— 改 message 的事，有时不如直接补个新 commit 来得稳妥。
