我是如何把小工具发布到 GitHub Release 的

工具写完之后，我用 GitHub CLI 创建仓库、推送源码、打版本标签，并把 Windows EXE 和 Web 静态包发布到 GitHub Release。

我是如何把小工具发布到 GitHub Release 的

工具能在本地运行，只是完成了一半。

如果一个工具想被别人看到、下载和长期使用，它还需要一个清晰的发布位置。对我来说，GitHub Release 很适合做这件事：源码放在仓库里，版本用 tag 固定，下载文件挂在 Release 下面，旧版本也能保留。

这次发布的是第一个小工具：

yuan-image-redactor

版本是：

v0.1.0

发布前先把本地整理干净

发布前，我先做了几件本地检查。

首先确认版本号一致：

• package.json
• src-tauri/tauri.conf.json
• src-tauri/Cargo.toml

它们都使用 0.1.0。

然后确认 .gitignore 不会把构建产物提交到源码仓库。像 node_modules/、dist/、release/、src-tauri/target/ 这类目录都应该留在本地或作为 Release 资产上传，而不是进入源码提交。

接着重新跑测试和构建：

npm run test
cargo test
npm run release:web
npm run release:win

这一步的意义是确保 GitHub 上的 v0.1.0 对应的是一个真的构建过、测试过、可以交付的版本。

创建独立工具仓库

我的 GitHub 账号是：

yuan0727

工具仓库创建为：

https://github.com/yuan0727/yuan-image-redactor

我使用 GitHub CLI 完成创建和推送。GitHub CLI 登录后，后续创建仓库、发布 Release、上传资产都可以在命令行里完成，比较适合重复化。

本地工具目录是一个独立 git 仓库，不和总索引仓库混在一起。首次提交信息是：

Initial release

打版本标签

推送 main 分支之后，我创建了 annotated tag：

v0.1.0

这个 tag 很重要。它把源码固定在某个明确版本上。以后如果发布 v0.1.1 或 v0.2.0，每个版本都有自己的标签和 Release，用户也可以回到旧版本下载。

这比只在 README 里写“当前版本”更可靠。

准备 Release 资产

这次 Release 上传了三个文件：

yuan-image-redactor-win-v0.1.0.exe
yuan-image-redactor-web-v0.1.0.zip
yuan-image-redactor-guide-v0.1.0.md

其中 EXE 是 Windows 桌面版，zip 是 Web 静态版，guide 是中文工具使用说明。

我没有把这些文件直接提交进源码仓库。原因很简单：源码仓库应该保持干净，Release 资产才是给用户下载的交付物。

这也是后续所有工具都应该遵守的规则。

发布说明

Release 页面还需要一段说明，告诉用户这个版本包含什么。

第一版说明重点写了：

• 这是首次公开发布。
• 包含 Windows 桌面版和 Web 静态版。
• 支持多图选择、拖拽打码、撤销和保存状态。
• 保存不会覆盖本地原图。
• 保存位置由系统或浏览器下载设置决定。

发布说明不需要写得花哨，但要让用户知道下载哪个文件、这个版本能做什么、有哪些需要注意的地方。

验证远端结果

发布完成后，我又做了一轮验证：

• 工具仓库是否存在。
• Release v0.1.0 是否存在。
• 三个资产是否都上传成功。
• 本地 git 状态是否干净。

最终发布地址是：

https://github.com/yuan0727/yuan-image-redactor/releases/tag/v0.1.0

这套流程为什么值得固定

这次发布看起来只是一个工具，但它其实建立了一套模板。

以后每个小工具都可以按这个流程走：

flowchart LR
  A["本地测试和构建"] --> B["提交源码"]
  B --> C["推送 main"]
  C --> D["创建版本 tag"]
  D --> E["创建 GitHub Release"]
  E --> F["上传 EXE 和 Web zip"]

只要流程稳定，工具越多，越能体现价值。

对我来说，GitHub Release 不只是下载页，它也是一个公开的交付记录。别人可以看到每个工具的版本、源码、说明和交付物，这比只放一个网盘链接更专业。