预发布版本管理不再难：release-it 的 alpha/beta/rc 工作流实战指南
预发布版本管理不再难release-it 的 alpha/beta/rc 工作流实战指南【免费下载链接】release-it Automate versioning and package publishing项目地址: https://gitcode.com/gh_mirrors/re/release-itrelease-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-releaserelease-it 把上面所有事情压缩成一条命令。它会自动判断当前版本是否已是预发布、续接正确的版本号-beta.0、-beta.1…、选择对应的 npm dist-tag并在 GitHub Release 上自动打上 Pre-release 标记。二、最快上手一条命令发出第一个 beta假设你的包awesome-pkg当前版本是1.3.0正在开发新的大版本。要发布第一个 betarelease-it major --preReleasebeta执行后会发生什么动作结果版本号自动变为2.0.0-beta.0Git提交并打 tagv2.0.0-beta.0push 时同步 tagnpm发布到beta通道npm install awesome-pkg仍安装稳定的1.3.0GitHub创建 Release 并自动标记为Pre-release这条命令等价于release-it premajor --preReleaseIdbeta --npm.tagbeta --github.preRelease即自动帮你补齐了所有关联参数这正是它好用的核心原因。三、alpha → beta → rc → 正式版完整工作流下面是预发布阶段推进的标准节奏完整说明见 docs/pre-releases.md1. 从 beta 继续迭代2.0.0-beta.1、2.0.0-beta.2…release-it --preRelease不指定版本号时release-it 检测到当前 tag 已是预发布就会自动续接下一个序号beta.0 → beta.1。2. 进入下一阶段发布 rcrelease-it --preReleaserc产出2.0.0-rc.0。想发多个 rc 就反复执行上一条命令。3. rc 验证通过发布正式版release-it major产出干净的2.0.0npmlatest通道更新。小贴士正式版发布时如果想把预发布期间的所有 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。五、三个关键选项速查选项作用示例--preRelease启用预发布传字符串则指定 id--preReleaserc--preReleaseId等价写法仅指定预发布 id--preReleaseIdbeta--preReleaseBase预发布序号从几开始默认从 0 开始--preReleaseBase1得到2.0.0-beta.1--git.tagExclude正式版 changelog 的起始 tag 排除规则--git.tagExclude*[-]*这些命令行参数在 lib/args.js 中注册默认值则收敛在 config/release-it.json例如 GitHub 侧的preRelease: false默认关闭避免误发。六、预发布如何聪明地联动 npm 与 GitHubnpm 通道自动推断发布预发布版本时lib/plugin/npm/npm.js 会优先使用你显式指定的npm.tag否则自动取预发布 id 作为 dist-tag发beta就发到beta通道用户用npm install awesome-pkgbeta安装。GitHub 自动标记 Pre-releaselib/plugin/github/GitHub.js 会解析版本号只要版本本身是预发布就自动设置prerelease: true无需手动在网页上勾选。单独覆盖所有联动都可以逐项覆盖例如release-it --preReleaserc --npm.tagnext。七、最佳实践与常见坑预发布要配合递增类型使用major--preRelease实际执行的是premajorVersion.js#L120-L122这是与约定式版本号的配合方式别指望手动拼2.0.0-beta.0的 tag。大版本之外想提前试水 v2.1在2.0.0-rc.0之后新增了不该进 v2 的功能时可以为下一个 minor 单开一条预发布线release-it preminor --preReleasealpha得到2.1.0-alpha.0两条预发布线互不干扰。序号从 0 还是 1 开始团队习惯不同用--preReleaseBase1统一即可避免beta.0看起来像没发过。发布前用 dry-run加--dry-run可预演整个流程见 docs/dry-runs.md确认版本号、tag 名、npm 通道无误再真正执行。八、延伸阅读预发布专题文档docs/pre-releases.md全量配置项说明docs/configuration.mdnpm 插件配置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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考