commit-rewriter 0.1：批量重写 Git 提交信息的开源工具

Simon Willison 发布了一款名为 commit-rewriter 的小型 Web 工具（版本 0.1），用于批量编辑 Git 仓库中的提交信息。这个项目源于一个真实痛点：在准备 Datasette 安全更新的公开发布时，早期提交里塞满了编程 Agent 生成的冗余内容，还夹带着私有仓库的 issue ID，直接对外发布并不合适。

工具解决的实际问题

随着 AI 辅助编程（AI-assisted programming）的普及，越来越多开发者依赖 coding agent 自动生成提交。这类自动化流程带来的副作用之一，就是提交信息里充斥着所谓的「cruft」——机器味十足的模板文本、内部引用、以及指向私有资源的链接。

对于开源项目而言，这些内容在公开发布前必须清理干净。手动逐条 rebase 编辑既繁琐又容易出错，commit-rewriter 正是为填补这个空隙而生。作者坦言，工具是「前几天」为处理 Datasette 安全发布临时搭建的，本质是一个针对具体工作流的自用小工具，而非大而全的解决方案。

上手方式极其简单

工具借助 uvx 免安装运行，一条命令即可启动：

uvx commit-rewriter path/to/repo

如果当前目录已经是目标仓库，则可省略路径参数，直接执行 uvx commit-rewriter。运行后会启动一个本地 Web 界面。

从官方截图可以看到，界面布局清晰：顶部显示仓库路径、当前分支与提交哈希；工具栏包含待编辑计数、丢弃草稿（Discard drafts）与执行重写（Rewrite commit messages）按钮，还提供了按消息、作者或哈希搜索的输入框，以及「仅显示已编辑」的过滤复选框。左侧边栏用于在提交历史间导航，主面板则为每条提交提供可编辑文本区，并支持展开查看完整格式化的 diff。

uvx 是 Python 包管理工具 uv 提供的命令，功能类似 npx——无需预先安装目标包，直接从 PyPI 拉取并在隔离环境中运行。这意味着用户不需要手动创建虚拟环境或执行 pip install，一条命令即可使用工具，用完后环境自动清理。uv 本身以极快的依赖解析速度著称，由 Rust 编写，是近年来 Python 生态中增长最快的工具链之一。对于「随用随走」的小工具场景，uvx 极大降低了试用门槛。

安全机制：可回退的时间戳分支

重写 Git 历史是高风险操作，一旦出错可能导致提交丢失。commit-rewriter 在这一点上做了防护设计：当你提交编辑后，工具会先基于当前仓库状态创建一个带时间戳的分支，作为回退备份，然后再从你编辑的第一个提交开始，一直重写到最新提交。

这种「先备份、后重写」的策略降低了误操作的代价。如果重写结果不符合预期，开发者可以随时切回那个时间戳分支恢复原状。对于需要修改历史但又担心不可逆后果的场景，这是一个务实的取舍。

Git 的历史重写本质上是重新生成提交对象——每个提交的哈希由其内容、时间戳、父提交哈希共同决定，修改提交信息会产生全新的哈希链，原有哈希不再出现在当前分支历史中。这正是 git rebase -i 或 git filter-branch 等命令需要谨慎使用的原因：如果修改已推送到远端的分支，所有协作者都必须强制同步，否则会出现历史分叉。commit-rewriter 的时间戳备份分支策略，本质上是在本地保留了一个指向原始提交链的引用，确保原始对象不会被 Git 垃圾回收，从而能随时切回。

定位与适用场景

commit-rewriter 目前还处于 0.1 阶段，属于典型的「够用就好」的个人项目。它的价值不在于功能多丰富，而在于把一个高频却烦人的清理任务变得可视化、可批量化。

最典型的适用场景包括：

• 将私有仓库代码开源前，清除内部 issue 引用和敏感链接；
• 清理 AI coding agent 自动生成的模板化提交信息；
• 为发布节点整理提交历史，让 changelog 更易读。

对于依赖 AI 编程工具、又需要维护公开代码质量的开发者来说，这类工具反映了一个正在浮现的新需求：如何在自动化生成与人工审校之间建立一道清理关卡。commit-rewriter 用极简的方式给出了自己的答案。