rerere 能在 rebase 冲突中自动复用旧解法，前提是已启用且此前解决过完全相同的冲突块（基于 preimage 哈希匹配）；启用后 git 自动创建 .git/rr-cache/，首次冲突即开始记录，后续相同冲突块可自动解决。
rerere 能在 rebase 冲突中自动复用旧解法，但前提是它已启用且之前解决过完全相同的冲突块（preimage 匹配）。
rebase 前必须确保 rerere 已启用
rerere 不会自动生效，哪怕你刚用 git config --global rerere.enabled true 开启，它也只对后续的冲突生效。如果你已在 rebase 中卡住，此时启用无效——必须先 abort 当前 rebase，再启用 rerere，然后重试。
- 检查是否启用：
git config rerere.enabled（返回true才有效） - 全局启用：
git config --global rerere.enabled true - 仅当前仓库启用：
git config rerere.enabled true（不加--global） - 启用后，Git 会在首次冲突时自动创建
.git/rr-cache/目录，无需手动建
rerere 匹配冲突靠的是“预像哈希”，不是文件名或行号
rerere 不关心你改的是哪一行、哪个分支，只比对冲突发生前的三路内容（base / local / remote）拼合出的“冲突块原始状态”。只要这个哈希值一致，就认为是“相同冲突”。
GitHub 项目更新追踪工具 - 自动检查多个 GitHub 项目的 Releases 和 CHANGELOG，生成更新摘要与影响分析报告。支持自动化定时任务。 如何使用 最简单的方式：直接用自然语言告诉我 你可以说 我会做 「检查 GitHub 更新」 检查最新版本 「添加 vscode」 追踪新项目 「停止追踪 xxx」 移除项目 「暂停更新检查」 暂停自动化 「给我看 openclaw 报告」 展示报告 触发词：「追踪项目更新」「检查 GitHub 更新」「项目更新报告」「设置更新提醒」
- 所以：同一文件里位置不同但内容相同的冲突块，
rerere不会识别为重复 - 反之：哪怕文件名、路径全变，只要冲突块的 base + local + remote 组合完全一致，
rerere就能复用 - 验证是否命中：
git rerere status显示文件名，git rerere diff可看到 preimage 和 resolution 的对比
rebase 过程中 rerere 自动触发的条件和限制
rerere 在 rebase 中不是“一键应用全部”，而是逐个冲突块尝试复用。它只在 Git 检测到冲突时介入，且只对它有记录的块生效。
- 当你运行
git rebase遇到冲突，Git 会自动调用rerere；无需额外命令 - 若成功复用，终端会输出类似：
Resolved 'src/utils.js' using previous resolution. - 若部分块匹配、部分不匹配，你会看到混合状态：有的文件已自动解决，有的仍需手动处理
-
git rebase --continue前，务必确认所有冲突都真正解决（git status应无 unmerged paths） - 注意：
git rebase --skip或--abort会触发git rerere clear，清空本次 rebase 的临时记录
常见失效场景和绕过方法
rerere 失效往往不是功能坏了，而是预像不匹配或配置未生效。最常被忽略的是“冲突块微小差异”导致哈希变化。
- 编辑器自动删行尾空格、换行符从 CRLF 变 LF、添加/删除注释——都会让 preimage 哈希改变
- 两次冲突之间，base 版本变了（比如 base 提交被 force-push 替换），rerere 记录作废
- 想强制刷新某文件的记录：
git rerere forget src/utils.js，再手动解决一次即可更新 - 清理陈旧记录：
git rerere gc（默认删 60 天前的 resolution 和 15 天前的 unresolved）
rerere 的价值不在“全自动”，而在“省掉重复劳动”。它不帮你判断逻辑对错，只忠实地回放你上次的手动选择——所以第一次解决时就得想清楚，否则下次它会原样照搬。
