git commit --fixup 是用于标记修补某次历史提交的专用命令，它自动生成形如 fixup! commit-message 的提交信息，但不改变工作区或暂存区；必须配合 git rebase -i --autosquash 才能自动合并到目标提交，单独使用无特殊效果，且不可用普通 -m "fixup!" 替代。
什么是 git commit --fixup，它和普通提交有什么区别？
git commit --fixup 不是另起一套提交逻辑，而是给 Git 一个明确的“修补”信号：这次提交只用于修正前面某次提交的内容。它会自动生成一条形如 fixup! commit-message 的提交信息，并把该提交哈希（前7位）作为前缀写进 message —— 比如 fixup! refactor: extract validation logic。
关键点在于：
- 它不改变工作区或暂存区行为，只是打标 + 自动生成 message
- 后续必须配合
git rebase -i --autosquash才能生效，单独提交毫无特殊效果 - 不能用
git commit -m "fixup!"替代，那样 Git 完全识别不出意图
为什么 rebase -i --autosquash 有时不自动合并 fixup 提交？
常见原因有三个：
-
fixup提交的 message 没对齐目标提交的 完整首行（注意：不是 commit hash，也不是任意子串），比如目标是feat(api): add user search endpoint，你写了fixup! add user search就匹配失败 - 目标提交在待 rebase 范围之外（比如你
git rebase -i HEAD~3，但fixup指向的是 HEAD~5 的提交） - 本地 Git 配置没开 autosquash：检查
git config --get rebase.autosquash，输出应为true；若为空，运行git config --global rebase.autosquash true
实际操作时怎么避免把 fixup 提交推到远程？
fixup 是临时整理工具，绝不能出现在最终分支历史里。最容易出错的环节是：
- 忘记执行
git rebase -i --autosquash，直接git push，结果远程多出一堆fixup!提交 - 在 rebase 过程中手动删掉了
fixup行，但没注意到对应那行的pick已被 Git 自动转成fixup或squash，导致目标提交没被修改 - 使用 VS Code 内置终端执行 rebase 时，编辑器默认关掉了
fixup行的高亮，容易漏看
推荐流程：改完代码 → git commit --fixup=abc1234 → git rebase -i --autosquash abc1234^（注意是 ^，表示从目标提交父节点开始 rebase）→ 保存退出 → git push --force-with-lease
和交互式 rebase 手动 squash 相比，--autosquash 真的更安全吗？
不一定更安全，但更可控。它不会跳过任何 fixup 行，也不会误合并无关提交 —— 前提是你 message 匹配准确。而手动编辑 rebase todo list 时，可能：
- 把
pick错写成squash却忘了改上面一行，导致提交 message 被清空 - 多个
fixup指向同一提交时，--autosquash会按时间顺序自动排成连续fixup行，避免手动排序错误 - 如果某次
fixup实际改了不该动的文件，rebase 过程中 Git 仍会报冲突，得人工解决，这点和手动方式完全一样
真正省掉的只是“记住哪些要合并、谁修谁”的认知负担，不是冲突或逻辑错误本身。
别指望 --autosquash 能绕过理解提交语义这一步。它只管“怎么合”，不管“该不该合”。
