2026 年 9 月 14 日，Datasette 作者 Simon Willison 在 PyPI 发布了本地审查工具 commit-rewriter 0.1。这一工具诞生的直接导火索，是他在准备 Datasette 9 月安全补丁时遇到的工程麻烦：版本演进的提交历史中，充斥着 AI 编程智能体留下的提示词碎片、冗长思考痕迹，以及大量指向内部私有仓库的 Issue ID。
对于向来要求严谨、可公开审计的安全更新来说，这些智能体垃圾信息不仅破坏了提交历史的整洁，更构成了合规层面的私有资产泄密风险。commit-rewriter 表面上是一个通过浏览器修改提交文案的本地应用，其底层实质却是一套绕过常规工作区检出的纯 Git 对象数据库重构器。
绕过工作区：Git 底层对象的高性能原子重构
修改 Git 提交历史向来是开发者最不愿频繁触碰的操作之一。在 Git 的底层拓扑中，修改单条提交说明意味着重算哈希，进而引发所有子代节点的连锁重写。传统工作流依赖 git rebase -i，但在长历史分支中，变基往往伴随繁琐的编辑器交互与意外冲突；而历史悠久的 filter-branch 重放机制容易丢失合并逻辑，脚本门槛更高的 git-filter-repo 则缺乏即时审查体验。
commit-rewriter 0.1 选择了更直接的底层路径。该工具基于 Python 3.11 及以上环境，支持通过 uvx commit-rewriter path/to/repo 免安装即时启动。后端由轻量级的 Starlette 与 Uvicorn 驱动，默认绑定在 127.0.0.1:8000 本地地址，配备了针对重写接口的 CSRF 防护与 Host 请求头校验，界面默认展示最近 100 条提交记录 并支持查看完整代码差异。
在执行修改时，该工具完全绕开了传统的重放命令，直接调用 Git 的底层 Plumbing 指令。它先通过 git rev-list 完成拓扑排序，定位修改范围；随后提取树对象与父提交，直接利用 git hash-object -t commit -w 将包含新文案的对象写入仓库底层数据库；最后借助带有 compare-and-swap 语义的 git update-ref 原子更新分支引用。这种设计不触发工作区的文件签出与合并计算，在保证极高执行速度的同时，规避了常规变基产生的树冲突。
为防止误操作摧毁历史，工具在重写前会创建一个高精度时间戳备份分支，命名遵循 commit-message-backup/YYYY-MM-DD-HHMMSS-ffffff-xxxxxx 规范，附带 UTC 微秒级时间戳与 6 位随机字符。
签名剥离与硬编码：0.1 版本的技术代价
这种极致追求低摩擦的底层重构方案并非没有代价。由于哈希变更在密码学上打破了原有的数字签名，commit-rewriter 在重构提交对象时，会强制剥离被修改提交及其后续所有子代节点中的 gpgsig、gpgsig-sha256 头部以及合并标签 mergetag，并在重写完成后统计已删除的签名数量。
对于严格推行软件供应链安全、要求所有入库提交均附带 GPG 签名的企业或开源团队，这种改写会导致审计验证链条直接失效。
开发者容易将该工具与 Rust 生态中的同名开源项目 atabits/git-commit-rewriter 混淆。检索历史可以发现，后者仅是对 Git 官方早已废弃的 filter-branch 命令做了一层 GUI 封装，在重写时会静默丢弃多行正文，只留下首行提交标题。Simon Willison 的版本则是基于 Python 对 Git 对象格式的原生重建，完整保留了多行提交正文的换行与结构。
但 0.1 版本的局限同样明显。该工具的重写目标分支在代码中被硬编码为 refs/heads/main，在遇到浅克隆仓库、未解决的冲突状态或存在冲突的外部 worktree 时，程序会主动抛出异常并拒绝执行。如果团队习惯在特性分支上完成历史整理后再合并，当前版本将无法直接支持。
智能体垃圾与表面脱敏的假性安全
commit-rewriter 能够受到社区快速关注，核心在于它击中了 AI 辅助编程普及后的普遍痛点。随着 Cursor、Claude Code 等编程助手深入日常开发，智能体生成的临时 Prompt、冗长的中间思考记录以及与研发任务关联的私有工单编号，正以前所未有的速度侵蚀提交历史。
生成代码只需几秒，清理代码历史里的碎片与泄密隐患却要耗费数倍代价。
但仅仅修改提交说明，往往会给工程团队带来表面脱敏的假性安全感。提交历史被重写后，原有的私有 Issue ID 虽然从最新的链条中消失，但它们仍然可能完好无损地残留在本地与远端的 reflog 日志、遗留的 Tag 注释、Git Notes 以及已被协作者克隆的 Fork 仓库中。只改文案而不进行全链路引用的级联清理，并不能算作严谨的信息消除。
此外，由于重写后的哈希与上游完全断裂，一旦开发者在协作仓库中执行简单的强制推送（git push --force），将极易覆盖队友的工作成果，必须严格配合 --force-with-lease 机制作为防线。
- 风险.盲目依赖提交信息重写容易制造假性安全感，真正的脱敏必须连带清理 reflog、标签注释与上游镜像中的残留引用。
commit-rewriter 用精巧的底层对象控制，降低了开发者“给智能体收拾历史”的摩擦成本。但它也提醒了技术团队：在 AI 肆意输出上下文的时代，如何从源头规范智能体的提交纪律，远比事后用重写工具拆解对象数据库更加重要。