github-release-notes

GitHub 发布说明生成器

为项目即将发布的版本生成可直接粘贴到 GitHub 发布页面的发布说明。遵循 Keep a Changelog 1.1.0 中“变更类型”的约定。

流程

1. 查找最新的发布标签：
   • git describe --tags --abbrev=0（备用命令：git tag --sort=-v:refname | head -n 1）
   • 如果不存在标签，则使用完整历史记录。
2. 列出自该标签以来的提交：git log <tag>..HEAD --no-merges --pretty=format:"%h %s"。
3. 如果存在 CHANGELOG.md，简要阅读以匹配项目的语气、语言和措辞风格，但不要修改或创建该文件。
4. 将每个提交归类到 Keep a Changelog 的一种变更类型中。没有条目的类型不输出。
5. 将发布说明输出为 Markdown，并用单个围栏代码块括起来，方便用户复制粘贴到 GitHub 发布页面。

变更类型（Keep a Changelog 1.1.0）

使用以下确切的标题标签，始终使用英文（请参阅“撰写规则”）：

• Added — 新功能
• Changed — 现有功能变更
• Deprecated — 即将移除的功能
• Removed — 已移除的功能
• Fixed — 错误修复
• Security — 漏洞修复

破坏性变更

Keep a Changelog 没有专门用于破坏性变更的类别。不要自行添加 Breaking 标题。应将每项破坏性变更列在最相关的类型下（通常是 Changed 或 Removed），并为该条目添加固定前缀 **Breaking:**——每次都必须使用这一确切的拼写和大小写，不能使用 **breaking change**、**BREAKING** 或其他变体：

### Changed
- **Breaking:** Renamed the `config.load()` option `path` to `configPath`

### Removed
- **Breaking:** Dropped support for Node.js 18

即使其余说明已翻译，**Breaking:** 标记也必须保持英文（请参阅“撰写规则”）。

输出格式

仅在单个围栏代码块中输出发布说明 Markdown。不要添加前言、结尾评论或外围说明。

不要包含版本标题（## [x.y.z]）或日期——GitHub 的发布页面已经会显示标签和发布日期，因此重复添加没有必要。直接从 ### 类型标题开始：

### Added
- Short, user-facing description of the change

### Fixed
- Short, user-facing description of the fix

撰写规则

• 每个条目占一行，面向用户，并描述影响，而非实现方式。
• 不要包含提交哈希或作者姓名。如果现有 CHANGELOG.md 已使用 PR 编号，则可以保留。
• 将重复或相关的提交合并为一个条目。
• 跳过纯内部改动（lint 配置调整、仅涉及 CI 的变更、格式整理、没有用户影响的依赖升级）；如果所有改动都属于此类，则将有意义的改动归入 Changed。
• 如果项目已有 CHANGELOG.md，则使用其中的语言；否则默认使用英文。
• 始终保留类型标题（Added、Changed、Deprecated、Removed、Fixed、Security）以及 **Breaking:** 标记的英文形式——即使用户明确要求将说明翻译成其他语言也是如此。只翻译条目描述；这些固定标签不得翻译。
• 完全省略没有内容的变更类型。