[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2ow0yg2hjq5rf":3},{"code":4,"message":5,"data":6,"timestamp":42},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":30,"summary_md":31,"topic":32,"github_topics":35,"license":36,"homepage":37,"updated_at":38,"history":39},"kunchenguid\u002Fno-mistakes",2,"git push no-mistakes","Go",8957,930,18,203,[16,22,27],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},47838708,"Show HN: Git Push No-Mistakes",19,6,"2026-04-20",{"id":23,"title":24,"points":25,"comments":25,"posted_at":26},49397509,"Git Push No-Mistakes",1,"2026-08-22",{"id":28,"title":24,"points":25,"comments":25,"posted_at":29},48696013,"2026-06-27","在本地 git 远端上跑 AI 审查与修复流水线，通过后才转发到 origin 并自动开 PR。","如果你已经在用编程 Agent 写代码，并希望它们的产出在交给人审之前先被过滤一遍，这个项目值得看看。但它对工作流的改动不小，不是加个钩子那么简单。\n\n## 解决什么问题\n\n改完一个分支、push、开 PR，然后在 review 里或 CI 挂了之后才发现漏掉的测试、过时的文档、lint 问题。如果代码是编程 Agent 写的，这些收尾其实落到了 reviewer 头上。`no-mistakes` 改的是 push 这一步：你不再 `git push origin`，而是推到本地的 gate 远端；只有 review、测试、文档、lint 全部通过后，分支才会被转发到配置的推送目标。结果是 PR 到达时机械性问题已经处理掉，而不是留给 reviewer 去分诊的初稿。\n\n## 有什么不同\n\n机制是在你和真实远端之间放一个本地 git 代理。往它推送会起一个一次性 worktree，流水线在你的工作区之外跑，不打断手上的分支；全部检查通过后才转发分支并自动开 PR。发现的问题按类型分开：机械性修复自动应用，涉及意图的则升级给你，在 TUI 里 approve、fix 或 skip。\n\n它比 pre-commit 钩子多做的一点是交互方式。[Show HN 讨论](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=47838708)里有人问为什么不直接用 pre-commit 钩子，作者回答说当 Agent 找出七个问题而你只在意其中四个、还想补充修复指令时，这种来回在钩子里很难表达（[回复](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=47851045:)）。流水线对 Agent 不挑剔，Claude、Codex、Copilot、Cursor 等可配有序回退；同一流程也做成 `\u002Fno-mistakes` 技能，Agent 可以无头跑任务、过 gate、应用安全修复。代价是你要信任一轮 AI 判定你的改动，而且必须配 Agent：每个 gate 都需要一个能跑的流水线 Agent。\n\nCI 失败处理是设计上最谨慎的地方。流水线会修复，并且只有在能证明修复基于你已审过的那个提交时，才通过受保护的 force-push 重新发布；证明不了一律退回 review，合并冲突的修复因为重写历史也总是走这条路。可以设 `ci.revalidate_repairs: true` 强制每次 CI 修复都重新审查，代价是每修一次多跑一整轮。\n\n## 谁值得试\n\n适合经常让 Agent 出分支、想在 Agent 与人工 review 之间加一道闸的开发者，尤其是能接受 approve\u002Ffix\u002Fskip 交互、愿意在配置里指定默认 Agent 的人。fork 贡献也有路径：`origin` 指向父仓库，用 fork URL 初始化即可。\n\n如果你只想要提交前的轻量本地检查，或者不打算把编程 Agent 纳入每次 gate，那它不合适。如果团队 review 本来就很细、PR 噪声很少，这轮额外检查未必划算。\n\n## 使用条件与边界\n\n你需要装好并跑得起来一个受支持的 CLI Agent，配置里写明它和回退顺序；没有这项 gate 跑不起来。安装还会改变远端结构：你推到 gate，由它转发到配置目标，原来的 `origin` 习惯和脚本要相应调整。\n\n日常维护比安装更要紧。CI 修复可能 force-push，所以才有了那条血缘证明逻辑和重新审查开关；打开重新审查意味着每次修复多一整轮 review。启用前先看[配置说明](https:\u002F\u002Fkunchenguid.github.io\u002Fno-mistakes\u002Freference\u002Frepo-config\u002F#cirevalidate_repairs)弄清它改了什么。macOS\u002FLinux 上一行命令安装，Windows、Go、Nix 和源码构建见[安装指南](https:\u002F\u002Fkunchenguid.github.io\u002Fno-mistakes\u002Fstart-here\u002Finstallation\u002F)；首次运行见[快速开始](https:\u002F\u002Fkunchenguid.github.io\u002Fno-mistakes\u002Fstart-here\u002Fquick-start\u002F)。\n\n## HotRepo 点评\n\nHotRepo 只记录到 2026-10-25 一次日榜出现，当时 8,947 stars、当天 +18，项目年龄 203 天。这只是单次观察，无法据此判断热度能否持续，也不必从中读出趋势。真正要决定的是：你是否愿意让每次推送都经过 AI 闸门并指定默认 Agent；先确认你的 Agent 在支持列表里，再决定 CI 重新审查怎么配。",{"slug":33,"name":34},"developer-tools","开发工具",[],"MIT","https:\u002F\u002Fkunchenguid.github.io\u002Fno-mistakes\u002F","2026-10-25T11:04:36Z",[40],{"date":41,"stars":11,"stars_gained":13},"2026-10-25",1792968629]