以后你合完 PR 就去喝咖啡，发版这事它自己干完才通知你

你有没有过这种时候：改完一个 bug，要手动改版本号、写 changelog、打包、登录 npm 后台、点发布……一不小心漏了某步，用户就用上带 bug 的新版本？

或者团队里三个人轮流发版，有人写“v1.2.3”，有人写“1.2.3-rc1”，还有人直接 push 到 main 就算完事——最后连谁发的哪版都对不上？

明明只是修了个小错，却因为版本号乱标，让下游项目不敢升级，怕踩坑？

版本管理不该是靠人盯、靠经验、靠运气的灰色地带。它本该是一条清晰、可预测、不依赖个体状态的确定性流程。

而现实是，很多团队把发版当成「收尾动作」，结果越拖越重，越重越怕动——直到某天发现主分支已经三个月没正式发布了。

它替你省掉了什么

semantic-release 不是替代某个具体付费软件，而是替代「人工发版」这个整套高风险、低价值、重复烧脑的劳动流程。

Trust us, this will change your workflow for the better.

它省掉的是：你花在查文档、翻 git log、比对 diff、手敲版本号、复制粘贴 changelog 上的时间；更是省掉因人为失误导致的线上事故、回滚成本和团队信任损耗。

很多公司为这类问题买了 CI/CD 增值服务或定制开发，比如 GitLab Premium 的高级发布策略、CircleCI 的企业级工作流插件，年费动辄几千到上万。而 semantic-release 是完全免费的。

价格直接砍到零。

但它真正省下的，是每次发版前那十分钟的紧张确认、半夜三点的紧急回滚、以及新同事第一次发版时反复问“我该改 package.json 还是 lerna.json”的尴尬。

主要能干这几件事

• 自动判断该发什么版本：不用人猜“这次算不算 breaking change”，它读 commit 消息就懂，比如写了 “feat: add dark mode”，就自动升 minor 版本；写了 “BREAKING CHANGE: drop IE11 support”，就升 major 版本。它不看代码内容，只认提交信息里的关键词和结构，所以规则透明、结果稳定。
• 自动生成 release notes：每次发版，它从最近的 commit 里挑出所有 feat、fix、perf 类消息，按类别整理成清晰的更新日志，直接贴进 GitHub Release 页面，不用你再整理一遍。生成的文本还能自动链接到对应 PR 和作者，点击就能溯源。
• 一次配置，多平台发布：npm、GitHub Packages、Docker Hub、甚至私有仓库，只要装对应插件，就能在同一个 CI 流程里全发出去，不用为每个平台单独写脚本。比如 @semantic-release/npm 插件负责推包到 npm，@semantic-release/github 负责创建 Release 页面，@semantic-release/docker 发布镜像，全部串在一条流水线里。
• 堵住不规范提交：配合 commitlint 工具，开发者一写错 commit 格式（比如只写“update readme”），CI 就直接报错不许合入，从源头守住语义化底线。commitlint 的配置文件 .commitlintrc.js 里可以精确控制哪些 scope 允许出现、哪些 type 必须带描述。
• 支持任意语言生态：虽然本身是 JavaScript 写的，但通过插件机制，它已用于 Python（PyPI）、Rust（crates.io）、Go（Gitea）、甚至 .NET 项目的自动化发布，文档里明确写了支持哪些包管理器。比如 Python 项目常用 @semantic-release/python 插件，它会自动调用 twine upload。
• 发布过程全程可审计：每一步操作（版本计算、changelog 生成、实际推送）都在 CI 日志里留痕，谁在什么时候触发了哪次发布，清清楚楚，不怕甩锅。日志里还会显示本次发布的完整语义化版本号、对应 git tag、以及所有被包含的 commit hash。

怎么开始用

1. 确认你的项目跑在 Linux 环境下（官方明确支持平台只有 Linux，macOS 和 Windows 需自行验证兼容性，README 未作保证）；
2. 去 GitHub 项目页（https://github.com/semantic-release/semantic-release）点右上角 Star，然后进 Releases 找最新稳定版，或直接用 npm 安装：npm install --save-dev semantic-release；
3. 在项目根目录加一个 .releaserc 配置文件，填两行基础设置（比如指定 npm 发布、用 Angular 提交规范），再把发布命令塞进 CI 脚本（如 GitHub Actions 的 workflow.yml），保存后下次合并 PR 就自动跑了。典型配置只需四行：{ “plugins”: [“@semantic-release/commit-analyzer”, “@semantic-release/release-notes-generator”, “@semantic-release/npm”, “@semantic-release/github”] }。

项目信息