企业官网建设流程全解析

预发布版本管理不再难：release-it 的 alpha/beta/rc 工作流实战指南

【免费下载链接】release-it🚀 Automate versioning and package publishing项目地址: https://gitcode.com/gh_mirrors/re/release-it

🚀release-it是一款自动化版本管理与包发布的 CLI 工具，它内置了对预发布版本（prerelease）的完整支持：一条命令即可完成 alpha、beta、rc 标签的打版、提交、推送与发布，让"从 1.3.0 走到 2.0.0-rc.0"这样的版本演进变成机械操作。

一、为什么预发布总是让人头疼？

正式大版本（比如 2.0）往往要经历alpha → beta → rc → 正式版的漫长过程。手工管理这些版本时，你通常需要：

• 手动改package.json里的版本号，还得保证符合 语义化版本 规则
• 打 git tag、写 release commit、push 并同步 tag
• 用npm publish --tag beta之类的参数发布到非 latest 通道
• 在 GitHub/GitLab 上手动创建 Release 并勾选 "pre-release"

release-it 把上面所有事情压缩成一条命令。它会自动判断当前版本是否已是预发布、续接正确的版本号（-beta.0、-beta.1…）、选择对应的 npm dist-tag，并在 GitHub Release 上自动打上 Pre-release 标记。

二、最快上手：一条命令发出第一个 beta

假设你的包awesome-pkg当前版本是1.3.0，正在开发新的大版本。要发布第一个 beta：

release-it major --preRelease=beta

执行后会发生什么？

这条命令等价于release-it premajor --preReleaseId=beta --npm.tag=beta --github.preRelease，即自动帮你补齐了所有关联参数，这正是它好用的核心原因。

三、alpha → beta → rc → 正式版：完整工作流

下面是预发布阶段推进的标准节奏（完整说明见 docs/pre-releases.md）：

1. 从 beta 继续迭代（2.0.0-beta.1、2.0.0-beta.2…）

release-it --preRelease

不指定版本号时，release-it 检测到当前 tag 已是预发布，就会自动续接下一个序号（beta.0 → beta.1）。

2. 进入下一阶段：发布 rc

release-it --preRelease=rc

产出2.0.0-rc.0。想发多个 rc 就反复执行上一条命令。

3. rc 验证通过，发布正式版

release-it major

产出干净的2.0.0，npmlatest通道更新。

💡小贴士：正式版发布时，如果想把预发布期间的所有 commit 都写进 changelog，可以加上--git.tagExclude='*[-]*'，让 release-it 从最近的非预发布 tag开始收集提交。

四、不知道参数填什么？交给交互式模式

release-it 不带参数直接运行时会进入交互式引导，版本递增选项会根据当前状态动态变化：

• 最新 tag 是预发布时：提供prerelease / patch / minor / major选项
• 明确指定了--preRelease时：只提供prepatch / preminor / premajor

这套选项逻辑定义在 lib/plugin/version/Version.js 中，版本号的实际递增由incrementVersion方法完成（Version.js#L93-L130）。

五、三个关键选项速查

这些命令行参数在 lib/args.js 中注册，默认值则收敛在 config/release-it.json（例如 GitHub 侧的preRelease: false默认关闭，避免误发）。

六、预发布如何"聪明地"联动 npm 与 GitHub？

• npm 通道自动推断：发布预发布版本时，lib/plugin/npm/npm.js 会优先使用你显式指定的npm.tag，否则自动取预发布 id 作为 dist-tag（发beta就发到beta通道），用户用npm install awesome-pkg@beta安装。
• GitHub 自动标记 Pre-release：lib/plugin/github/GitHub.js 会解析版本号，只要版本本身是预发布就自动设置prerelease: true，无需手动在网页上勾选。
• 单独覆盖：所有联动都可以逐项覆盖，例如release-it --preRelease=rc --npm.tag=next。

七、最佳实践与常见坑

1. 预发布要配合递增类型使用：major+--preRelease实际执行的是premajor（Version.js#L120-L122），这是与约定式版本号的配合方式，别指望手动拼2.0.0-beta.0的 tag。
2. 大版本之外想提前试水 v2.1？在2.0.0-rc.0之后新增了不该进 v2 的功能时，可以为下一个 minor 单开一条预发布线：release-it preminor --preRelease=alpha（得到2.1.0-alpha.0），两条预发布线互不干扰。
3. 序号从 0 还是 1 开始：团队习惯不同，用--preReleaseBase=1统一即可，避免beta.0看起来像"没发过"。
4. 发布前用 dry-run：加--dry-run可预演整个流程（见 docs/dry-runs.md），确认版本号、tag 名、npm 通道无误再真正执行。

八、延伸阅读

• 预发布专题文档：docs/pre-releases.md
• 全量配置项说明：docs/configuration.md
• npm 插件配置：docs/npm.md、GitHub 发布配置：docs/github-releases.md
• 版本号核心逻辑源码：lib/plugin/version/Version.js
• 交互式引导 GIF 与预发布演示动图位于 docs/assets/ 目录

掌握这条alpha → beta → rc → 正式版的流水线后，预发布就从"高危手工操作"变成了随手一条命令的日常动作。✨

【免费下载链接】release-it🚀 Automate versioning and package publishing项目地址: https://gitcode.com/gh_mirrors/re/release-it