别再盲目相信 Git 的 Success 提示了

在公司带团队做代码 Review 的时候，我发现很多同学有个习惯：只要终端跳出 Successfully rebased and updated 或者 Merge made by the 'recursive' strategy，就觉得万事大吉了。但我最近在处理一个复杂的 Stacked PR（堆叠式拉取请求）仓库时发现，Git 嘴里说的“成功”，有时候跟实际的文件状态完全是两码事。

我总结了几个在实际开发流程中非常容易被忽视、甚至会导致代码逻辑错误的 Git 细节，特别是关于 rerere 和 autosquash 的用法。

一、 关于 rerere 的两个“反直觉”逻辑

rerere (reuse recorded resolution) 本意是让你在多次 rebase 过程中重复解决同一个冲突时，Git 能自动帮你把之前的解决结果“复读”一遍。但在实战中，有两个细节如果不注意，它根本不会生效。

• 仅仅 git add 是没用的：

很多教程会让你在解决冲突后执行 git add，然后觉得 Git 就记住了。错了。如果你解决完冲突，执行了 git add，紧接着因为某种原因执行了 git rebase --abort，那么 rerere 的元数据会被直接清空。
想要让它真正记录，你需要显式地触发一个“完成”动作，比如 git commit 或者在 rebase 过程中通过 git rerere 确认。

• 它是按内容匹配，而不是按路径：

这是一个很危险的点。如果你在 file_A.txt 里解决了一个冲突，Git 记住了这个冲突块（hunk）的处理方式。如果你在另一个完全不同的 file_B.txt 里也遇到了内容一模一样的冲突块，Git 会“自作聪明”地把 file_A 的方案直接套用到 file_B 上。如果这两个地方的业务逻辑并不一致，这就是灾难。

二、 为什么我强烈建议关掉 rerere.autoupdate

在配置 rerere 时，大家经常会看到两个配置成对出现：

git config rerere.enabled true
git config rerere.autoupdate true

但我个人的实战经验是：一定要把 autoupdate 关掉。

• 开启后（Autoupdate ON）：Git 觉得它帮你解决了冲突，会自动把文件内容更新并直接 stage（暂存）好。你甚至不会发现它动了你的代码，直到你提交后才发现逻辑不对。
• 关闭后（Autoupdate OFF）：Git 虽然会自动把解决后的内容写进文件，但它会保持“冲突状态”（UU），强迫你去看一眼。这其实是一个人工校验的“检查点”。

如果 Git 真的猜错了，你可以用这两条命令救命：

# 丢弃 Git 记录的错误解决方案
git rerere forget

# 把冲突标记（<<<<<<< HEAD）重新找回来
git checkout -m

三、 --autosquash 并不是万能药

用 git commit --fixup <hash> 配合 git rebase -i --autosquash 是整理提交记录的神器，但它有两个极容易踩的坑：

1. 范围不足不会报错：如果你执行 rebase 时指定的范围（range）不够深，没覆盖到那个 fixup! commit，Git 不会给你任何警告。它会一脸淡定地打印出 Successfully rebased and updated，但实际上那个 fixup! 提交还傻傻地躺在你的历史记录里，没被合并进去。
2. 务必检查历史：每次做完这类操作，养成习惯跑一下这个命令，看看是不是还有没处理掉的 fixup：

git log --oneline | grep fixup!

在复杂的协作环境下，别把 Git 的反馈当成真理，多看一眼 git status 和 git log 永远是最稳妥的工作流。