前言
最近想给自己的开源项目添加发布脚本,主要实现交互命令行,选择新版本类型 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,如果是用的开源包出了问题,还没人修复,这时就可以自然而然地动手去改并提交给作者了。
真要说参与开源社区的难点在哪,我真不觉得是技术,而是英语!不论是填写说明、求助、还是和别人讨论问题,我都会反复纠结这句话语法对不对,语气是不是礼貌......大家一定要学好英语啊😭。