Git amend：检查暂存内容后修正最后提交

示例与前提

例子是一个普通本地提交，信息有误且漏了src/parser.js更改。仅改信息和同时改内容是两种修复。它不针对更早的提交、初始提交或需要特殊检查的merge。替换文件名和信息，并从当前末尾开始。

修改前检查状态

检查status、最后提交和diff --cached。普通amend使用索引，因此其他任务暂存的文件可能意外进入替换提交。也检查未暂存部分，理解哪些在外。改变身份之前，确认原提交是否已push、合并或被同事使用。

git status --short
git log -1 --oneline
git diff --cached
git diff

保留引用或独立检出

在HEAD创建rescue/before-amend以便比较原对象，但它不保存所有本地编辑。重要文件另行保存。reflog可能找到仍被保留的旧引用状态，但不保证对象永久保留，也不是从未提交过的编辑备份。

git branch rescue/before-amend HEAD

第一种操作

仅修改信息时，无路径的--amend --only排除已暂存更改，-m提供修正信息。之后检查新提交和索引，原暂存工作应仍可用于独立提交。要包含索引内容是另一流程，即使两者都使用amend。

git commit --amend --only -m "Fix parser error message"
git diff --cached

有意选择另一种结果

补文件时暂存目标路径，检查整个索引diff，再用--amend --no-edit保留信息。其他已暂存文件若不有意排除也会进入。运行项目检查。选择部分hunk便于审查，却不能证明最终组合提交正确。

git add -- src/parser.js
git diff --cached
git commit --amend --no-edit

限制与例外

若末尾已共享，优先新增修正提交。发布重写末尾可能需要协调，保护分支还可能禁止。这里没有通用force push命令。团队明确允许时，使用其独立的lease、分支和协作者检查流程。

git add -- src/parser.js
git diff --cached
git commit -m "Correct parser handling"

冲突与清理

amend通常没有自己的冲突继续流程。hook失败或提交被拒绝时，检查信息与状态，而不是自动reset --hard。改错内容先与rescue/before-amend比较。任何修正reset之前保留已经验证的本地文件副本。

验证结果

比较两个提交的文件和信息。ID不同是正常的。仅改信息时树应相同；改内容时只有预期补丁不同。检查剩余暂存工作，并保留救援引用直到已审查替换安全进入所需历史。

git show --stat HEAD
git diff rescue/before-amend HEAD
git status --short

常见问题

no-edit不会禁止内容变化，它只保留信息，索引仍可改变内容。amend不能直接修正更早提交，需要另一历史编辑流程。push之后应服从明确的共享历史政策，也可用额外修正提交避免协调问题。

在FluxGit中审查操作

使用FluxGit的可视历史与差异视图审查操作及相关提交。保留本例中的分支、共享历史和本地文件检查。下载页面列出当前提供的版本及平台。

Git官方文档

• git-commit
• git-diff
• git-reflog