git-tidy：一个把「提交规范治理」做成闭环的 Git 桌面客户端

团队历史越积越乱，CHANGELOG 靠手搓，commit-msg hook 装了没人守------这大概是每个被 git log 刷屏过的开发者都熟悉的场景。git-tidy 想做的，不是又一个长得像 SourceTree 的客户端，而是把「判定不合规 → 就地改写 → 度量结果 → 生成日志」串成同一个闭环，并且让每一步改写之前你都能看清将要发生什么。

为什么又造一个 Git 客户端？

先说清楚：git-tidy 不是要替代你手里的 Git 客户端，也不是终端清理脚本。它把两件事塞进了同一个进程：

一套通用的历史浏览与仓库操作能力（提交图、diff、blame、分支标签、stash、远端同步、冲突解决......）；
一套提交规范治理闭环------这才是它真正的重点。

单独看每一环你都能找到替代品：git-cliff 能生成 CHANGELOG，Commitizen 能规范输入，GitButler 的 virtual branches 能做提交级压缩。但把这些环节串起来、并且在任何一次改写之前都能看清将要改什么，目前没有现成方案。

这正是 git-tidy 的出发点。

规范治理闭环是怎么转起来的

很多人不是不知道规范，而是缺少一个「看得见、改得动」的把手。git-tidy 的闭环由这几环构成：

三层配置，兼容既有生态 。团队规范写在仓库根的 git-tidy.config.json，个人偏好在 preferences.json，本地索引用 SQLite（WAL + busy_timeout）。更关键的是：当没有自研配置时，它会按序从 commitlint.config.js / .commitlintrc*、.versionrc.json、cliff.toml 推导等价规范。也就是说，你已有的 Commitlint / standard-version / git-cliff 配置零迁移成本直接复用，自研格式只是覆盖手段，而不是唯一入口。
可视化提交表单 。type / scope / subject / body / footer / 任务 ID，实时校验与预览，空 subject、无信息量词、中文冒号、句尾句号等都会被拦截。提交走 git commit -F，和你手敲的完全等价。
commit-msg hook 一键安装 。规则以字面量写进一份自包含的 POSIX 脚本，安装时拍快照，不依赖本工具在 PATH 里。如果你已经用 husky 占用了 core.hooksPath，它不会强行覆盖，只给你一套共存方案。
符合率报告 。整体符合率、type 分布、原因分桶、按作者与按月趋势，每条不合规明细都能跳到详情和 diff。被 --no-verify 绕过的提交在 git 里不留痕迹，所以报告里只标「疑似绕过」，而不是武断断言。
CHANGELOG 生成 。按 Conventional Commits 1.0.0 解析，Breaking 判定同时覆盖 type 后的 ! 与 BREAKING CHANGE: footer，按 feat / fix / perf / refactor 分组、scope 作二级、revert 单独成组。不合规的提交不会被静默丢弃，而是单独计数并链回报告------你能看到「为什么这条没进日志」。

历史改写引擎：最硬的一块骨头

发现不合规只是第一步，能不能就地整改 才是关键。git-tidy 能对 HEAD 往回的任意连续区间做 reword / squash / fixup / drop / 重排，而且区间可以位于历史中部，不只是最近几条。

实现上有个反直觉的决定：它不用 git rebase -i。

原因是实打实的工程坑：

GIT_SEQUENCE_EDITOR 需要 git 反向回调客户端，在 Windows 上还得维护一个单实例互斥进程；
崩溃后 todo 状态极难诊断。

所以 git-tidy 改成自驱引擎：rev-list --reverse 生成 todo，在临时分支上按序执行，每一步做 tree 校验，成功后再用 update-ref 回到原分支。

安全兜底也做在了 Rust 侧：

区间内任一提交已被 remote-tracking 包含时拒绝执行 ，除非你显式确认要改写已推送历史并接受 --force-with-lease 的后果；
区间含 merge commit 时拒绝；
squash 与 drop 保留原作者与作者日期；
执行前写入还原点，执行后校验最终 tree 与改写前一致，任何一步失败自动回退，临时分支保留供诊断。

换句话说：哪怕改写中途崩了，你也能回到改写前的状态，而不是面对一个半截历史。

隐私与安全：默认就站在你这边

这是个纯本地应用，不自建服务端。

出网面被显式枚举得清清楚楚：clone / fetch / pull / push / 更新检查（只查 api.github.com 一个 URL）/ 可选的 AI 端点。除此之外全部离线可用------不做遥测、不做账号体系、不代理 AI 请求、不缓存送出的 diff。

AI 生成提交信息是完全可选 的：你自带 OpenAI 兼容端点（OpenAI / DeepSeek / 通义 / 本地 Ollama 任意 /chat/completions 都行），在设置里填 Base URL / API Key / 模型名才启用。

API Key 一律由你自己提供。项目不内置、不附带、不分发任何 key，空即未启用，未启用时不发任何请求；发出的请求也只会到你填的那个地址。

即便开了 AI，它也只把 git diff --cached 的原文送给模型，与提交按钮要落盘的范围严格一致；结果先进弹窗，确认后才填入表单，不提供自动提交。报错文本里可能被网关回显的 key 会被抹掉------因为错误文案会被截图、被粘进 issue。

安全模型还守着一条底线：WebView 可以调用任意 command，所以所有 git 命令只接受已注册仓库的 id，路径由 Rust 侧解析；写命令必须在 write_guard 白名单内登记，未登记的 action 直接拒绝，前端传不了 argv 数组与文件路径；只读仓库在解析路径那一步就拒绝全部写命令。

谁适合用 git-tidy

个人开发者：想养成好的提交习惯，又不想每次都跟自己较劲记规范；
小团队：想要一致的历史风格和能直接发的 CHANGELOG，但没精力搭一整套 CI 卡点；
开源项目维护者：需要清晰的 Breaking Changes 标记和可读的发布说明。

如果你已经在用 Commitlint + git-cliff，git-tidy 几乎零成本接管，并补上「看到不合规 → 直接改掉」这最后一块拼图。

现状与如何参与

git-tidy 目前是 v0.1.0-beta.1（预发布版） ：首个 beta 已于 2026-10-12 发布，提供了 Windows（.exe / .msi）、macOS（.dmg）、Linux（.AppImage / .deb / .rpm）的安装包，到 Releases 页面直接下载就能用，不必自己编译。

如果你更想从源码跑，也可以：

bash 复制代码

git clone https://github.com/qbbyte/git-tidy.git
cd git-tidy
npm install
npm run tauri dev      # 启动桌面窗口
npm run tauri build    # 产出安装包（Windows 走 NSIS）

前置条件主要是 Rust MSVC 工具链与系统 WebView 依赖，详见仓库 README。

项目仍处于早期 beta 阶段，欢迎大家上手试用、以 Issue 反馈问题、以 PR 提交改动。涉及架构或工程约束的改动，建议先开 Issue 讨论。

最后

git-tidy 想解决的不是「怎么看 Git 历史」，而是「怎么让 Git 历史一直值得看」。它把规范从一份没人读的文档，变成了一套你能看见、能量化、能就地修的东西。如果你也受够了乱糟糟的 git log，不妨去仓库看看------现在就能装上 beta 试试，路线图也已经在那里了。

仓库地址：https://github.com/qbbyte/git-tidy
许可证：MIT

如果你对「提交规范治理」这个方向有想法，欢迎在 Issue 里聊聊------这工具还很年轻，方向由用的人一起定。