Git-knife

一句话定位

一个桌面软件，让你像编辑电子表格一样改 git 提交的元数据——提交信息、作者名/邮箱、作者日期、提交者日期，都能改，还能批量查找替换。说白了就是"给 git 历史做手术的 GUI 手术刀"。

做这个东西的人

HN 用户 YonathanTesfaye（GitHub 账号 TheRealYT）做的个人项目，仓库 TheRealYT/git-knife，Tauri（Rust 后端 + TypeScript 前端）写的桌面应用，2026 年 8 月 10 日建仓，8 月 11 日发 Show HN。v0.2.0 状态，README 自称 MVP。

判断：个人开发者 + 一次性解决自己踩过的坑，这类工具通常是"先有痛、后有产品"。从 README 的细致程度看，作者对这个 niche 的边界想得很清楚——哪些能做、哪些刻意不做，都写了。

它到底能做哪几件事

• 改提交元数据 → 提交信息、作者名/邮箱、提交者名/邮箱、作者日期、提交者日期，全部可编辑
• 批量查找替换 → 对信息、作者/提交者名、邮箱做字面或正则批量替换（"把旧邮箱统一换掉"这类场景），带预览和实时匹配计数
• 不改文件内容 → 内部不重新实现 git，而是调系统 git CLI，用 git commit-tree 重建提交、复用原有 tree，所以"文件内容可证明从未被改动"
• 不检出的分支浏览 → 按 ref 直接查看/编辑任何本地分支，不需要 checkout，工作区完全不动
• 安全网 → 每次重写前自动存备份 ref，一键恢复；改到已推送历史会警告；对签名提交打标、警告会撕掉签名、支持用你的密钥重新签名
• 可审计的透明性 → 每次重写会在独立的 notes ref 上留一条"被 git-knife 编辑过"的说明，正常 git log 看不见但完全可查，可一键关闭

它刻意不做：不重新排序/压缩/删除提交（规划中未实现），不动合并提交，不主动推送——推送永远是你的步骤，而且它只碰本地分支。

它在替代什么旧行为

改 git 提交历史以前是"没有好工具"的处境，两条路都有坑：

一是 GitKraken、Sublime Merge、Fork、lazygit 这类 GUI——改提交信息、重新排序做得好，但把提交日期当成基本不可变，暴露不了提交者日期，也不能批量改作者身份。想改日期，GUI 全都没戏。

二是 git filter-repo、git rebase 的环境变量技巧、git commit-tree 这类 CLI——能改一切元数据，但全在终端里：没有界面、语法繁琐、容易出错，而且一个命令下去就是全仓重写，普通人不敢碰。

git-knife 填的正是这个交集：能改全部字段的 GUI。它把"会改"的 CLI 能力装进"好看"的 GUI 外壳里，同时用备份 ref、警告、notes 标记把"改历史"这个高风险动作变得可逆。

商业模式

无。 个人开源项目，无定价、无赞助、无托管服务。README 也没有声明任何开源许可证（GitHub API 的 license 字段为空）。

判断：没许可证比没商业模式更值得注意。对一个工具来说，"能不能用在你的项目里"取决于许可证，作者到现在没选一个，可能是疏忽，也可能是还没想好。这不会挡住 star，但会挡住它进企业——想在生产里用的人会因为这个字段犹豫。

硬数字

• 294 star / 9 fork，2026-08-10 建仓，四天出头
• HN Show HN：池记录 143 分 / 88 评论，Algolia 显示 165 分 / 101 评论
• v0.2.0，MVP 状态；TypeScript + Tauri（Rust），三平台（macOS/Linux/Windows）安装包靠 GitHub Actions 出
• 评论区明确列出真实使用场景：还原历史（重建 Tim Berners-Lee 原始浏览器仓库时让提交日期对齐）、拆仓库保留历史、修正开源 PR 合并时的归属错误、修 agent 弄乱的 git config
• 下载量、用户数：未披露

四维评估

判断

这是一个"把没人做的脏活做精致"的典型样本，且恰好踩中了 AI 时代的新痛点。

可迁移的规律：找一个"大家都觉得能改、其实没有好工具"的角落。 改 git 日期这件事，几乎所有开发者都默认"做不到"或"不值得做"，但评论区证明真实需求一直存在——simonw 列了还原历史、拆仓保留历史、修正归属三个场景，还有人专门找这种工具找了近十年（"用一个 git 仓库存法律条文，每个提交是一部法案，需要插进历史而不重置后续日期"）。被主流工具放弃的字段，就是新工具的机会。

它踩中的新痛点：AI agent 写代码后，git config 被 agent 弄乱、提交归属错乱、日期和真实工作流对不上——这是最近才出现的一类问题。git-knife 的"批量改作者邮箱"刚好接住它。

名字起得好。Git-knife——"手术刀"——评论区自己就把这个隐喻接上了："一般我们不想切开人，但真需要手术时，锋利的刀很有用。"名字让用户瞬间理解这是一把危险但有价值、要用得谨慎的工具。

风险：一是没许可证，挡住企业采纳；二是它处理的是"已推送历史"这种高危动作，一次误用就能毁掉团队协作，信任门槛极高；三是定位停留在"改元数据"，评论区已经有人要求扩展成完整 rebase UI（拖拽排序、调整文件归属）——如果作者不接住这些需求，更强的竞品会接。

下一步看什么

① 三个月后 star 能否破千——衡量"被主流工具放弃的角落"这个需求有多大 ② 作者是否补上许可证——决定它能不能从个人工具变成生产工具 ③ 是否出现完整 rebase UI 的功能（拖拽排序/压缩/改归属）——决定它是窄工具还是往主流工具的方向长

可借鉴的做法

产品逻辑：任何"大家都默认做不到"的操作，值得先验证一下是不是真的没人做——往往只是没人做好。列出主流工具刻意放弃的字段/能力，那里就是空白市场。git-knife 的对比表（工具 × 能力矩阵）是值得抄的调研方法：把自己的位置精确标在别人都打不了勾的那一格。

定价结构：无。未开源许可证、未定价，个人项目状态。

结论

值得关注。 定位精准、安全设计到位、正好接住 AI 时代的提交混乱问题，但没许可证、没商业模式、还停在"改元数据"这一格。盯着 star 增速和功能扩展这两条看它会不会从手术刀长成完整工具。