为什么前端项目一定要用release-it？这3个痛点它能一次性解决
你可能会说：“我手动部署也挺快的啊，改个版本号、git push、npm publish，三步就完了。” 这话我两年前也信，直到我统计了团队一个月的部署数据：手动部署时，平均每5次发布就有1次版本号错误，每8次就有1次忘记生成变更日志。这些小错误看起来不大，但每次排查都要花1-2小时，更别说生产环境出问题时的紧急回滚有多糟心。
手动部署的3个“隐形坑”，你肯定踩过至少一个
第一个坑是版本号管理混乱。前端项目常用语义化版本（SemVer），即v主版本.次版本.修订号（比如v1.3.2），但手动改的时候很容易搞错——我见过有人把修复bug的修订号（patch）当成次版本（minor）加，结果用户看到版本号以为有大功能更新，实际只是修了个按钮样式。更麻烦的是多人协作时，你改了package.json的版本号，同事没拉代码就提交，直接造成冲突。
第二个坑是发布流程不标准。正规的发布流程应该是：更新版本号→生成CHANGELOG→Git提交→打标签→推送到远程→部署到服务器。但手动操作时，很容易漏掉某一步，比如只改了版本号没打标签，后来想回滚到上个版本都找不到对应代码。我之前接手一个老项目，发现Git标签乱七八糟，v1.0.0、v1.0、v1.0.0-beta混在一起，根本分不清哪个是正式发布的版本。
第三个坑是重复劳动浪费时间。一个前端项目从开发到发布，至少要经历“本地测试→测试环境→预发布→生产环境”4个阶段，每次环境切换都要改配置、输命令。我之前算过，手动部署一个中型React项目，从准备到完成平均要25分钟，其中15分钟都在重复输入git add .、git commit -m “release”、git push origin main这些命令。而用release-it的话，这些步骤能一键自动化，相当于每次发布帮你省出1杯奶茶的时间。
release-it凭什么成为前端部署“神器”？这4个优势你不得不服
可能你用过Jenkins、GitHub Actions这些CI/CD工具，觉得它们更强大，但对中小型前端项目来说，release-it的优势在于轻量、灵活、零学习成本。它不需要你搭服务器、写复杂的YAML配置，装个依赖、改个配置文件就能跑，连实习生看一遍教程都能上手。
我去npm官网查了下，release-it每周下载量超过100万次，在GitHub上有10.5k星标，比同类工具standard-version、semantic-release更受欢迎（数据截至2023年11月，来源：npm trends，nofollow）。为什么这么多人用？我 了4个核心优势：
npx release-it，然后按几次回车，8分钟就能完成从本地到生产的全流程。"hooks": {"before:release": "npm run lint"}，就能自动触发检查，不通过就终止发布。从0到1配置release-it，这5步照做，新手也能10分钟跑通
说了这么多优势，你肯定想知道：到底怎么配置才能用起来？别担心，我把流程拆成了“安装→配置→关联Git→测试→发布”5步，每步都配了具体命令和截图级说明，你跟着敲就行。这里要提醒一句：release-it依赖Git和npm，所以先确保你本地装了Git（ 2.20.0以上）和Node.js（14.0.0以上），我之前用Node.js 12跑的时候报错，升级到16就好了。
第1步：5分钟装好release-it，这2行命令就能搞定
首先打开你的前端项目（Vue/React/Angular都行，我以React项目为例），在终端里输入：
npm install release-it save-dev
或者用yarn：yarn add release-it dev
安装过程中可能会遇到依赖冲突，比如提示“peer dependency conflict”，这时候不用慌——先看看是不是其他依赖和release-it版本不兼容，我 直接加force强制安装（仅限开发环境，生产环境慎用）：
npm install release-it save-dev force装完后，你可以先跑npx release-it version看看是否安装成功，出现版本号（比如15.11.0）就说明没问题。这一步很简单，但有个小细节： 把release-it装在项目依赖里（save-dev），而不是全局，这样团队其他人拉代码后不用单独安装，直接用项目里的版本，避免版本不一致导致的问题。
第2步：配置文件怎么写？记住这3个核心配置项就够了
release-it的配置有3种方式：命令行参数、package.json里的release-it字段，或者单独的.releaserc文件（JSON/JS格式）。我推荐用单独的.releaserc.js文件，因为可以写注释，后期维护更方便。在项目根目录新建.releaserc.js，然后复制这段基础配置：
module.exports = {
"git": {
"commitMessage": "chore: release v${version}", // Git提交信息格式
"tagName": "v${version}", // 标签名称格式， 加v前缀
"push": true // 自动推送到远程仓库
},
"npm": {
"publish": false // 暂时关闭npm发布，测试阶段用不到
},
"hooks": {
"before:init": ["npm run test"] // 发布前先跑测试，失败则终止
},
"github": {
"release": false // 暂时关闭GitHub Release
}
};
你可能会问：“这些配置项都是什么意思？能不能自定义？” 当然可以，我整理了前端项目最常用的8个配置项，你可以根据需求修改（表格里标⭐的是必配项）：
| 配置项路径 | 作用 | 默认值 | 是否必配 |
|---|---|---|---|
| git.tagName | Git标签名称格式， 用v${version}区分版本 | v${version} | ⭐必配 |
| git.commitMessage | 版本更新的Git提交信息， 加”release”标识 | chore: release ${version} | 可选 |
| npm.publish | 是否自动执行npm publish（组件库项目常用） | true | 可选（前端应用 设为false） |
| hooks.before:init | 发布前执行的命令（如测试、lint） | [] | ⭐必配（ 加测试命令） |
| plugins.@release-it/conventional-changelog | 集成标准化CHANGELOG生成插件 | – | 推荐（下文会讲安装） |
这里插一句：如果你想自动生成CHANGELOG（就是记录每次发布改了什么的文件），需要额外装个插件@release-it/conventional-changelog，命令是npm install @release-it/conventional-changelog save-dev，然后在.releaserc.js里加一段配置：
"plugins": {
"@release-it/conventional-changelog": {
"preset": "angular", // 用Angular的提交规范，也可以换成"conventionalcommits"
"infile": "CHANGELOG.md" // 生成的文件名称
}
}
这个插件会根据你的Git提交信息（比如feat: 添加登录组件、fix: 修复按钮点击无响应）自动分类生成CHANGELOG，再也不用手动写“本次更新内容”了。我团队用了这个插件后，产品经理再也没找过我们要“更新说明”——他们直接看CHANGELOG就够了。
第3步：关联Git仓库，这2个检查项千万别漏
release-it核心功能依赖Git，所以必须确保你的项目已经关联了Git仓库，并且所有修改都已提交（没提交的代码会导致发布失败）。你可以先在终端里跑git remote -v，看看是否有origin远程仓库，比如：
origin git@github.com:你的用户名/项目名.git (fetch)
origin git@github.com:你的用户名/项目名.git (push)
如果没有，先通过git remote add origin 仓库地址关联。然后检查工作区是否干净：git status，确保没有红色的“untracked files”或“changes not staged for commit”。我之前有个同事，配置完release-it就急着发布，结果因为有个改了一半的文件没提交，直接导致发布中断，还得重来一遍。
确保你有权限推送到主分支（main/master），很多公司的Git仓库默认保护主分支，需要手动开启“允许推送标签”权限。你可以先手动推一个标签试试：git tag v1.0.0 && git push origin v1.0.0，如果成功就没问题；如果提示“permission denied”，找你们团队的Git管理员开权限就行。
第4步：先跑“测试发布”，这3个问题提前解决
配置完别急着正式发布，先用dry-run参数跑一遍“假发布”，检查流程是否有问题。在终端输入：
npx release-it dry-run这时候release-it会模拟发布流程，但不会真的修改版本号、推送到Git或发布到npm，非常适合测试配置是否正确。跑的时候注意看终端输出，这3个常见问题要提前解决：
"before:init": ["npm run test"]，而测试用例有失败，release-it会终止流程。这时候别删hooks，先把测试用例改对——发布前跑测试是为了避免把bug推到生产，这步不能省。git commit -m "改了点东西"，插件就识别不出这是feat还是fix。正确的写法是git commit -m "feat: 添加用户列表页"（前缀+冒号+空格+描述），具体规范可以看Conventional Commits官网。我第一次跑dry-run时，就因为提交信息写的“更新了样式”，导致CHANGELOG为空，后来把提交信息改成“fix: 修复首页导航栏样式错位”，就正常生成了。
第5步：1分钟完成正式发布，记住这2个快捷键
测试没问题后，就可以正式发布了。在终端输入npx release-it，这时候release-it会问你3个问题：
如果一切顺利，终端会显示“✅ Release done”，这时候你去Git仓库看，会发现多了一个标签（比如v1.0.1），package.json的版本号也更新了，CHANGELOG.md里多了新的记录。我团队现在发布都用这个流程，最快的一次从执行命令到完成发布，只用了6分钟——比之前手动部署快了4倍！
这里有个小技巧：如果你想跳过交互，直接用默认配置发布，可以在命令里指定版本类型，比如npx release-it patch（直接发布修订号）、npx release-it minor（直接发布次版本），适合你确定版本类型的场景。我通常在修复小bug时用npx release-it patch，一步到位，连回车都不用按。
对了，发布完成后别忘告诉测试和产品同事——你可以在Slack或企业微信里发个消息：“v1.0.1已发布到生产，CHANGELOG见项目根目录，主要修复了登录按钮点击无响应的问题”。这样大家就知道这次发布改了什么，不用挨个解释啦。
你按照这5步配完之后，试试发布一个测试版本，比如从v1.0.0升到v1.0.1。如果遇到问题别慌，先看看终端的错误提示，大部分问题都能在release-it的GitHub Issues里找到答案——我之前遇到的“标签推送到Git失败”问题，就在
你是不是经常改完代码要发布时，盯着package.json里的版本号发呆：到底该把1.2.3的最后一个数字加1，还是中间那个？其实记个简单的“场景对应法”就行，不用死记规则。比如你今天改了个按钮点击没反应的bug，或者修复了移动端适配时卡片错位的问题，这种不影响现有功能、只是“修修补补”的操作，就选patch版本——也就是把版本号最后一位数字加1，比如从1.2.3变成1.2.4。我之前带实习生时，他第一次改了个表单验证的小bug，非要把中间的数字从2改成3，结果测试同事看到版本号1.3.3，还以为上了什么新功能，跑过来问了半天，后来我就教他“修bug就动最后一位，准没错”。
那什么时候动中间的数字（minor版本）呢？如果你加了新功能，但老用户用起来完全没感觉，比如给后台管理系统加了个数据导出按钮，或者给首页轮播图加了个自动播放开关，这些“添东西但不添麻烦”的更新，就把中间的数字加1，比如1.2.4变成1.3.0。我去年帮一个电商项目改版本号，他们加了个商品收藏功能，既没改商品详情页的布局，也没影响下单流程，我 用minor从1.3.5升到1.4.0，结果产品经理一看就明白这是加了新功能，而不是随便改了个数字。至于最前面的主版本号（major），你可得小心动它——只有当你改的东西会让老用户“用不了”时才用，比如把接口从/api/user改成/api/v2/user，或者把Vue 2的项目升级到Vue 3导致之前的组件全报错，这种“颠覆性”的更新才需要把第一位数字加1，比如从1.4.0变成2.0.0。我见过最夸张的一次，有团队为了“显得更新频繁”，三个月把major从1.0.0升到3.0.0，结果用户每次升级都要改代码，最后直接弃用了他们的工具，所以major版本一定要谨慎，非到万不得已别碰。
release-it和semantic-release有什么区别？该选哪个？
两者都是自动化发布工具，但定位不同：release-it更轻量，配置简单（几行代码就能跑），适合中小型前端项目或新手快速上手；semantic-release功能更全（支持多平台发布、自动生成GitHub Release等），但配置复杂（需要写YAML文件），适合大型项目或有复杂发布需求的团队。如果你的项目主要需要“版本号管理+CHANGELOG生成+Git标签”这三个核心功能，选release-it足够；如果需要更定制化的流程（如自动发布到多个平台、与CI/CD深度集成），可以考虑semantic-release。
如何确定该选择patch、minor还是major版本号？
遵循语义化版本（SemVer）规则：patch（修订号，如1.0.1→1.0.2）用于修复bug（如按钮样式错误、兼容性问题）；minor（次版本，如1.0.2→1.1.0）用于添加新功能但不破坏现有功能（如新增一个页面、添加搜索按钮）；major（主版本，如1.1.0→2.0.0）用于不兼容的重大更新（如API接口变更、框架升级导致旧功能无法使用）。不确定时，优先选patch（小修复）或minor（新功能），major谨慎使用，避免用户升级后出现兼容性问题。
为什么CHANGELOG.md生成后内容为空？怎么解决？
大概率是Git提交信息不符合规范导致的。release-it的CHANGELOG生成依赖“标准化提交信息”（如feat: 添加登录组件 fix: 修复表单验证bug），如果提交时写git commit -m “改了点东西”，工具无法识别类型，就会生成空文件。解决方法：① 提交时按“类型: 描述”格式写信息（类型包括feat、fix、docs、style等）；② 安装commitlint工具强制规范提交信息（命令：npm install @commitlint/cli @commitlint/config-conventional save-dev），避免不规范提交。
使用release-it发布后发现问题，如何回滚到上一个版本？
分三步操作：① 删除本地和远程Git标签：git tag -d v1.0.1（删除本地）、git push origin v1.0.1（删除远程）；② 回滚package.json版本号：手动改回上一版本（如从1.0.1改回1.0.0），并提交：git commit -m “revert: rollback to v1.0.0″；③ 重新发布（可选）：如果需要覆盖错误版本，可使用npx release-it force强制发布（注意：npm仓库不允许重复发布同一版本号，若已publish需先删除远程npm包再重发）。
非npm项目（如使用yarn或pnpm）可以用release-it吗？
可以。release-it支持所有包管理器，只需调整安装和配置命令：用yarn安装时，命令为yarn add release-it dev，发布时用yarn release-it；用pnpm安装时，命令为pnpm add release-it save-dev，发布时用pnpm exec release-it。配置文件中若涉及npm相关设置（如”npm”: { “publish”: false }），无需修改，release-it会自动适配当前包管理器的配置。
