从提交历史生成变更日志是什么
变更日志的初稿可以直接从提交历史里提取：用 git log 限定版本区间，按提交类型筛选，把标题整理成列表。前提是提交信息遵循统一规范，否则分组只能靠人工。生成出来的内容还需要润色——合并、回退与内部重构通常不需要出现在面向用户的日志里，而面向用户的措辞也往往要改写。它是发布流程中很省事的一环，但并非全自动。
基本信息
| 用途 | 按区间提取提交生成日志素材 |
|---|---|
| 常用参数 | --oneline、--no-merges、--grep、--pretty=format |
| 区间写法 | v1.4.1..v1.4.2 指定两次发布之间 |
| 输出 | Markdown 或纯文本列表 |
| 平台 | 任意 Git 客户端 |
典型使用场景
- 准备发布说明，先拉出本版本的全部改动
- 按类型分组，分别整理新增、修复与破坏性变更
- 核对本次发布是否遗漏了应对外公布的改动
- 维护项目的变更日志文件，减少手工整理
- 审计某区间是否夹带了不该发布的提交
- 给测试与运维提供本次改动的范围清单
按版本区间提取
按版本区间提取
git log --oneline --no-merges v1.4.1..v1.4.2
git log --no-merges --pretty=format:'- %s (%h)' v1.4.1..v1.4.2
git log --no-merges --grep '^feat' --pretty='- %s' v1.4.1..v1.4.2 # 新增
git log --no-merges --grep '^fix' --pretty='- %s' v1.4.1..v1.4.2 # 修复常用参数
| 参数 | 作用 |
|---|---|
| --no-merges | 排除合并提交，避免噪音 |
| --grep | 按标题里的类型前缀筛选 |
| --pretty=format | 自定义输出格式，便于直接贴进日志 |
| --reverse | 按时间正序输出，符合阅读习惯 |
自动生成后仍需人工润色：合并、回退与重构类提交通常不必出现在用户可读的日志里。
面向用户的描述往往要从提交标题改写而来，提交标题面向开发者、日志面向使用者，两者受众不同，措辞调整是必要环节。
发布说明的整理顺序
- 先用 --oneline 拉出区间内全部提交，核对条数
- 按类型分组：新增、修复、破坏性变更、内部改动
- 删掉面向开发者无意义的合并与重构条目
- 把破坏性变更单独突出，附上迁移说明
- 最后通读一遍，确认措辞对使用者可读