暂时还没有内容。请在上方粘贴几行内容，然后点击生成。它对每一行做了什么
规则被刻意设计得简单且可见，让你能预测结果，而不是靠猜测：
- Conventional commit 会按类型分组。`feat` 变为“新增”，`fix` 变为“修复”，`perf` 变为“改进”。冒号前的 `!`，或 BREAKING CHANGE 标记，会将该行归入“破坏性变更”，与其原本的类型无关。
- 不属于 conventional commit 的内容会按第一个词排序。Add、Added、Introduce 和 Support 归为“新增”；Fix、Fixed 和 Resolve 归为“修复”；Improve、Update、Speed 和 Optimise 归为“改进”；Remove、Removed、Drop 和 Deprecate 归为“移除”。其余内容会进入“其他”，由你手动整理。
- 噪音会被清除：结尾的 pull request 编号、`Merge pull request ...` 这样的整行内容、括号中的范围，以及 conventional 类型前缀本身。剩余的句子会以大写字母开头。
- 启用过滤后，`chore`、`ci`、`test`、`build`、`style` 和 `refactor` 相关的行会被丢弃，任何看起来像依赖更新的内容也是如此。这是人们会阅读的 changelog 和他们不再阅读的 changelog 之间最大的单一区别。
它做不到的事
它重写的是你提交信息的形式，而不是内容。如果一条提交写的是 `fix: race in MembershipCache.resolve()`，那么生成出来的仍然是这句话，依然是一句关于代码本身、而不是用户体验的话。要把“MembershipCache 中的竞态问题”变成“被邀请的成员不再看到空白的仪表盘”，需要知道这个变更实际做了什么，而这正是生成器无法从提交主题中推断出来的部分。
因此，请把输出结果当作第一稿：结构正确、分组正确、内部噪音已经清除，但措辞仍需要你自己修改。
常见问题
我粘贴的内容会被上传吗？
不会。生成器是这个页面上的一段脚本；文本永远不会离开你的浏览器，点击“生成”也不会向我们发送任何请求。你可以打开网络面板来确认这一点。
我必须使用 conventional commits 吗？
不必。遵循这一约定的行会被更准确地分组，其余内容会回退到根据开头的动词处理。使用普通句子式提交信息的仓库，同样能生成一份可用的草稿。
如何从我的仓库自动获取这些内容？
对于一次性使用，`git log --pretty=format:%s v1.2.0..HEAD` 能准确提供这里所需要的输入。对于持续使用，git-cliff 和 github-changelog-generator 都能在 CI 中根据你的提交历史构建一个 changelog 文件，而 Changeloop 会为每一个已合并的 pull request 生成一条面向用户的条目，并保留供审核。
为什么我的输出里全是“其他”？
开头的动词没有匹配到任何已知类别，这通常意味着提交主题是以名词或工单 ID 开头的。你可以在生成前先在输入框中修改，或者之后手动整理“其他”类别中的内容。
延伸阅读：从 conventional commits 到一份 changelog，了解提交格式能带来什么、以及它的局限在哪里。