前言
最近想给自己的开源项目添加发布脚本，主要实现交互命令行，选择新版本类型 major/minor/patch → 自动修改 package.json 的 version → 执行测试 → 执行构建 → 生成 changelog → 提交本地 git → 发布到 npm → 创建 git 标签 → 代码推送到 GitHub。
然后我就想到 Vue 仓库里就有完整的 scripts/release.js，所谓站在巨人的肩膀上，在我把源码看完一遍之后，不出意外就是要出意外了，😊果然被我发现破绽了吧！
test命令写错了，虽然由于pnpm的特性不影响运行，但肯定更正一下更好。- Vue release 脚本提供了
dry-run模式，即尝试运行，不会真的发布，可根据打印的日志信息，让开发者核对发布的内容是否正确。由于脚本自动修改了package.json，导致pnpm publish --dry-run的 git 检查过不去，这种保护机制是为了避免开发者遗漏了未提交的代码，实际上我们并没有修改源码，所以应该加上--no-git-checks禁用 git 检查。 - 第三处就是华为水 Linux PR 🤗最喜欢的单词拼写错误啦。
正题
第一步在 GitHub 上 fork 一份 Vue 的代码。
把 fork 的自己的仓库克隆到本地，建立一个新分支专门修复该问题，这也是 git 的正确使用方式，每个大功能和问题修复都建立单独的分支，并且规范分支命名，后续有问题回看的时候一目了然。新功能分支一般叫 feat/xxx，问题修复分支一般叫 fix/xxx，这里命名如下：
bash
git checkout -b fix/scripts-release然后咔咔把问题改好，将刚才创建的本地分支推送到 GitHub。这里需要注意的是，热门的开源仓库都比较规范，少不了代码格式、git 日志格式等等的校验，如果发现代码在本地提交不上，根据报错提示修改即可。
bash
git push -u origin fix/scripts-release:fix/scripts-release推荐用 VS Code 操作，git 命令记起来确实烦：
之后 GitHub 会自动提示你可以向源仓库提交 PR：
然后填写自己这次修复的详细说明，点击最下方的提交即可。
最后就是等待作者合并啦。有一说一，昨天看到 PR 被合并的邮件还是非常开心的~
写给开源新手的话
其实我第一次用 GitHub 的时候也是一脸懵逼，根本不知道放点什么上去，去改什么，怎么改，甚至有一次我错误地把同步别人的代码搞成了提交 PR，里面全是自己的测试代码，真是尴尬的要死。现在回头看，新手期真的不用着急，代码写多了，就会遇到 BUG，如果是用的开源包出了问题，还没人修复，这时就可以自然而然地动手去改并提交给作者了。
真要说参与开源社区的难点在哪，我真不觉得是技术，而是英语！不论是填写说明、求助、还是和别人讨论问题，我都会反复纠结这句话语法对不对，语气是不是礼貌......大家一定要学好英语啊😭。