git-cliff 2.14.2 从 git 提交历史生成 changelog，压缩包 6582272 字节，主程序 12088320 字节，一条命令把 feat: fix: 这类前缀整理成分组条目。
它要解决的是：发版前翻几十条提交记录，手动抄成分类清单，抄完还得对齐格式。
这次在一个新建的、有 12 个提交的仓库里从头跑了一遍，量了三种写法的耗时，也遇到了没有配置文件时的警告。
一个 12088320 字节的 exe
压缩包里三个可执行文件，主程序之外还有补全脚本生成器和 man 页生成器。
| 文件 | 字节 | 用途 |
|---|---|---|
| 压缩包 | 6582272 | git-cliff-2.14.2-i686-pc-windows-msvc.zip |
| git-cliff.exe | 12088320 | 主程序 |
| git-cliff-completions.exe | 1975808 | 生成 shell 补全 |
| git-cliff-mangen.exe | 1910784 | 生成 man 页 |
三个 exe 加起来 15 MB
12088320 加 1975808 加 1910784 是 15974912 字节。如果只要主功能，后两个可以不放，程序照常运行。
Windows 只给了 i686 构建
发布页的 Windows 包是 i686-pc-windows-msvc.zip，没有 x86_64 版本。32 位程序在 64 位 Windows 上能直接跑，这次实测没有遇到问题。
12 个提交生成 194 字节
在一个只有 12 个 feat: 提交的仓库里跑，三种写法耗时都在 80 毫秒以内。
| 写法 | 耗时 | 输出字节 |
|---|---|---|
| 无参数 | 78 ms | 194 |
| --unreleased | 72 ms | 194 |
| -o out.md | 76 ms | 0，写进文件 |
三种写法差 6 毫秒
78、72、76，差别在误差范围内。这个量级下，选哪种写法只看你要输出到屏幕还是文件，不用考虑速度。
12 条提交变成 194 字节
输出是 ## [unreleased] 加一行 ### 🚀 Features，再跟 12 条 - Add file N。原始 feat: 前缀被去掉，动词提到句首，这是默认配置做的清理。
没有 cliff.toml 会警告
仓库里没有配置文件时，它不报错，但会往 stderr 打一行警告。
| 情况 | 行为 |
|---|---|
| 有 cliff.toml | 按配置的模板与分组生成 |
| 没有 cliff.toml | 用内置默认配置，stderr 打 WARN |
| 仓库不是 git 目录 | 直接失败 |
![git-cliff 2.14.2 在一个有 12 个提交的仓库里输出的 changelog：顶部一行 WARN 提示 cliff.toml 未找到改用默认配置，正文是 ## [unreleased] 与 ### 🚀 Features，下面跟 12 条 - Add file 0 到 - Add file 11，下半段是 git log --oneline 的输出，每条带 7 位 hash 与 feat: 前缀](/uploads/evidence/220/real_202593f2e5.png)
警告原文
输出是 WARN git_cliff@0:0:0 -> "cliff.toml" is not found, using the default configuration。只看 stdout 会以为一切正常，实际上你用的是默认模板。
默认模板只认常见前缀
内置配置按 feat、fix、doc、perf 这几类分组，自定义前缀（比如 chore(deploy):）会被归到 Other 或直接丢掉，要精确控制就得写 cliff.toml。
输出还带着转义码
重定向到管道或文件时，彩色输出的 ANSI 序列不会被剥掉。
| 观察项 | 结果 |
|---|---|
| stderr 那一行 | 含 [0m[1m[90m 等转义码 |
| stdout 正文 | 194 字节里不含转义码 |
| 写入 out.md | 194 字节纯 Markdown |
正文干净，警告不干净
stdout 的 194 字节是纯 Markdown，可以直接贴进 release note。带转义码的只有 stderr 那条警告，脚本里把 stderr 丢掉就行。
写文件时不带颜色
-o out.md 生成的 194 字节和 stdout 一致，没有颜色码，说明它按输出目标判断过。
和 git log 摆在一起看
截图下半段是同一个仓库的 git log --oneline，两边的对应关系很清楚。
| git log | git-cliff |
|---|---|
| 一串 7 位 hash | 没有 hash，只有条目 |
| feat: add file 0 | - Add file 0 |
| 按时间倒序平铺 | 按类型分组，组内倒序 |
hash 被去掉是刻意的
changelog 给用户看，hash 对用户没意义。想保留 hash 得改模板，默认模板里没有这个字段。
分组来自前缀，不是 AI 分类
它按提交信息里冒号前那一段做归类，写什么分什么。提交信息不规范时，输出就会乱，这一步靠人管。
什么场景值得上
有发布节奏、每次要写 changelog 的项目。
| 场景 | 合适度 | 说明 |
|---|---|---|
| 发版前生成 changelog | 高 | 12 条提交 78 毫秒出结果 |
| CI 里自动产出 release note | 高 | -o 写文件，输出无颜色码 |
| 提交信息不规范的项目 | 低 | 分组会乱，得先统一前缀 |
| 单人小项目偶尔发版 | 低 | 写 cliff.toml 的时间比手抄还长 |
用它的前提是提交信息规范
它不猜语义，只按前缀归类。团队里有人写「修复一下」这种提交，生成出来就是一堆 Other。
授权与费用
MIT 或 Apache-2.0 双许可，个人与商业环境都不收费。源码在 GitHub 上，主要语言 Rust，发布页覆盖 Windows、macOS、Linux 三平台。
