git-knife：把 Git 提交元数据摊成一张表来改
阅读时间: 大约 9 分钟
git-knife：把 Git 提交元数据摊成一张表来改
git-knife 是 GitHub 用户 TheRealYT 开源的一个桌面 GUI（Tauri v2 构建，前端 Web 技术栈 + Rust 壳），口号是”Stab your git history into shape”。它解决的是一个长期被主流 Git 客户端忽视的缝隙：干净地编辑任意提交的元数据——提交信息、作者时间（author date）、提交者时间（committer date）、作者与提交者的姓名和邮箱。本文基于其官方 README 做一手梳理。
一、它到底补了哪个空缺
作者在 README 里把现有工具按能力分成两类，结论很直接：
- 漂亮的 GUI（GitKraken、Sublime Merge、Fork、SmartGit、git-cola、lazygit）：reword、reorder、squash 都做得不错，但把提交日期——尤其是 committer date——当成事实上不可变的，也不暴露任意提交的作者身份供批量修改；
- 能改元数据的 CLI（git-filter-repo、
git rebase环境变量技巧、git commit-tree）：能力齐全，但没有 GUI，门槛高、易出错。
git-knife 要做的就是这个交集：一个干净的 GUI，能批量、安全地编辑每一个字段。
二、官方能力对比（README 原表）
| 工具 | 干净 GUI | 改信息 | 重排/压缩/丢弃 | 改 author date | 改 committer date | 改作者/邮箱 | 批量正则查找替换 |
|---|---|---|---|---|---|---|---|
| git-knife | 是 | 是 | 🚧 计划中 | 是 | 是 | 是 | 是 |
| GitKraken | 是 | 是 | 是 | 仅 amend | 否 | 受限 | 否 |
| Sublime Merge | 是 | 是 | 是 | 否 | 否 | 仅 amend | 否 |
| Fork | 是 | 是 | 是 | 否 | 否 | 受限 | 否 |
| SmartGit | 是 | 是 | 是 | 受限 | 否 | 是 | 否 |
| git-cola | 半 | 是 | 是 | 是 | 否 | 是 | 否 |
| lazygit (TUI) | 终端 | 是 | 是 | 否 | 否 | 受限 | 否 |
| git-filter-repo | 无 GUI | 是 | 经回调 | 是 | 是 | 是 | 是 |
（图例：✅ 一等公民 / ⚠️ 可用但别扭或受限 / ◐ 终端 UI / ❌ 不支持 / 🚧 计划中）
这张表是作者自己列的，需要注意其立场：它当然把自己放在”唯一全绿”的位置。但其中”committer date 不可编辑""无批量正则改作者身份”这两点，与主流 GUI 的实际行为吻合，属于可信观察。
三、技术机制：为什么”文件内容不会被改”是可信承诺
这是 git-knife 最核心、也最值得肯定的设计选择。作者强调它从不自己实现 Git：
- 它直接调用系统安装的 git CLI（要求 git 2.x）；
- 改写提交时用
git commit-tree重建提交对象，并且复用每个提交原本的 tree 对象。
由于提交内容（tree 指针）原样保留，只替换 author/committer 元数据与 message，因此从 Git 对象模型上可证明文件内容没有任何变化。这和”重写文件再 diff”的思路有本质区别——它改的只是提交对象上的标签信息。
其他机制亮点：
- 无需 checkout：按 ref 直接编辑任意本地分支，工作区和当前检出分支完全不动；
- 跨 merge 编辑：重建整条提交图，保留每个 merge 的父节点；
- 改前预览：所有改动先高亮成行，Review & apply 时给出 old→new 预览；
- 自动备份：每次改写前打一个备份 ref（
refs/knife-backup），应用内 Backups 面板一键恢复，CLI 也能git reset --hard <backup-ref>。
四、批量查找替换与签名处理
批量模式是它的主打场景：勾选目标字段（message / 作者或提交者姓名 / 邮箱任意组合），输入 Find/Replace，可切换正则（支持 $1 反向引用），面板会实时统计匹配的提交数与替换数。README 给的典型例子是”把所有提交从旧邮箱迁到新邮箱”——一次修掉历史里写错的 old@example.com。
签名提交是这类工具最容易出事的地方，作者处理得相当透明：
- 改写会改变 commit hash，从而使 GPG/SSH 签名失效（README 提到这是 Hacker News 上的一条质疑）；
- git-knife 通过读取原始
gpgsig头来识别签名提交，不依赖验证结果——因此即便没有配置allowedSignersFile也能识别 SSH 签名； - 它会在表格里给签名提交打标，在应用栏警告”本次改写会剥离 N 个签名”，并提供重签开关（用你配置的
user.signingkey/gpg.format）； - 若开启重签却没配 key，应用会安全地在动任何 ref 之前失败，而不是改出一堆无签名历史。
此外它默认会在独立的 notes ref（refs/notes/git-knife）上附一条公开说明记录，普通 git log 里不可见，可随时查”这个仓库是否被 git-knife 编辑过”。
五、口径与局限：README 自己写明的边界
- MVP 状态：重排 / squash / drop、staging、分支与远程管理尚未实现（标 🚧 planned）。也就是说它现在是”元数据编辑器”，不是”交互式 rebase 全能器”。
- 不替你 push：它从不联系远程、从不替你推送；改写后 hash 全变、分支与远程分叉，需要你自己用
git push --force-with-lease（README 明确反对裸--force，因为后者跳过了对端是否移动的安全检查）。 - 触碰已推送历史会警告：当编辑深入到上游已存在的提交时弹出提示；README 建议”尽量只改未推送的提交”，因为改写共享历史会逼着协作者重新同步。
- 构建产物未签名：GitHub Actions 自动出 macOS/Linux/Windows 安装包，但没有做代码签名——README 直言”适合早期试用者”，企业分发会遇到系统拦截。
- 依赖系统环境：需要本机 git、Node+pnpm、Rust stable；Linux 上还要装一堆 Tauri v2 系统库（webkit2gtk-4.1 等），并非双击即装。
六、客观分析：优势与适合人群
优势： 把一个”能干但吓人”的底层能力（commit-tree 重写）封装成带预览、备份、签名感知的 GUI；机制上用复用 tree 的方式守住了”不动文件内容”这条安全底线；批量正则改邮箱是真实高频痛点。
适合： 历史里用错了私有邮箱、想一次性换成 noreply 邮箱的人；需要调整提交时间线做整洁提交历史的个人开发者；对签名提交有要求、又怕手滑的团队。
不适合： 需要重排/squash 的复杂历史整理（暂不支持）；不愿处理 force-push 协调的共享分支；对二进制未签名安装包敏感的生产环境。