https://x7peeps.com/AI/07-AI%E8%BE%85%E5%8A%A9%E5%BC%80%E5%8F%91%E5%B7%A5%E5%85%B7%E9%93%BE/GitHub-mergeable_state-%E4%B8%8D%E5%8F%AF%E4%BF%A1%E5%AE%9E%E5%BD%9531-%E4%B8%AA-PR-%E6%89%B9%E9%87%8F%E5%B7%A1%E6%A3%80%E7%9A%84%E7%9C%9F%E4%BC%AA%E5%86%B2%E7%AA%81%E5%88%86%E6%8B%A3/index.html一套每天自动巡检仓库 Pull Request 的无人值守会话，某天面对的是 31 个开放中的 PR。GitHub API 返回的合并状态里，29 个写着 mergeable_state=unknown。此刻脚本站在一个分岔路口：把 unknown 当成「有冲突」去 rebase，或者当成「可合并」去合——两条路都是错的，而且第二条更危险。这次巡检最终把 29 个「未知」拆成了 8 个真冲突和 21 个缓存噪音，全程没有动一次不该动的分支。这篇文章把整个处置链拆开讲：为什么 unknown 不能当判词、用什么办法在不依赖 GitHub 缓存的前提下完成真伪分拣、rebase 的六步安全链怎么走、一次「上游已修复」的等价判定怎么下、以及一个从 2.2GB 涨到 9.2GB 的 .git 目录是怎么在眼皮底下长出来的。Hugozh-CN