类型：代码托管平台
简介：只支持Git作为唯一的版本库格式进行托管，故名GitHub。
GitHub Releases 适合把项目的稳定版本、安装包、更新说明和源码快照集中展示出来。很多开源项目只在 README 里写“最新版已发布”，但没有使用 Releases，用户就很难判断该下载哪个版本，也看不到每次更新改了什么。对维护者来说，Releases 不只是一个下载页，更是项目版本管理和对外沟通的入口。
一、发布前先准备版本内容
发布 Release 前，先确认本次版本包含哪些改动。可以从合并过的 Pull Request、关闭的 Issue、提交记录和里程碑中整理。版本说明不要只写“修复若干问题”，至少区分新增功能、修复问题、兼容性变化和已知限制。若项目面向普通用户，还应把技术提交改写成能理解的说明。
版本号建议采用清楚规则。常见写法是 v1.2.0，其中主版本表示不兼容变化，次版本表示新增能力，修订号表示修复。项目不一定必须严格使用语义化版本，但要保持一致，避免一会儿写 1.0，一会儿写 release-final。
二、创建或选择 Tag
进入仓库首页，点击右侧 Releases，选择 Draft a new release。GitHub 会要求选择 Tag。可以选择已有 Tag，也可以在页面上新建 Tag，例如 v1.2.0。Tag 一般指向某个提交，表示这个提交就是该版本的代码状态。
如果团队习惯命令行，也可以先本地打 Tag：
git tag v1.2.0 git push origin v1.2.0
然后回到 GitHub Releases 页面选择该 Tag。网页端新建 Tag 更简单，但命令行更适合和本地测试、构建流程结合。
三、填写 Release 标题和说明
Release 标题可以直接使用版本号加简短说明，例如“v1.2.0：新增批量导入和修复登录异常”。正文建议分段写：新增内容、修复问题、升级提醒、已知问题。GitHub 支持 Markdown，因此可以使用列表、链接和代码格式。
如果项目使用 Pull Request 管理开发，可以在说明中链接相关 PR 或 Issue，例如“修复 #18 中的上传失败问题”。这样用户能追踪背景，维护者以后回看版本也更清楚。
四、上传安装包或构建产物
如果项目需要分发二进制文件、压缩包、桌面软件安装包，可以在 Release 页面上传附件。GitHub 会自动提供 Source code zip 和 tar.gz，但这只是源码快照，不等于构建好的安装包。需要用户直接运行的软件，应上传构建产物。
附件命名要清楚，例如 project-windows-x64-v1.2.0.zip、project-macos-arm64-v1.2.0.dmg。不要使用 final.zip、new.zip 这类模糊名称。不同系统、不同架构要分开标注，避免用户下载错误文件。
五、预发布版本什么时候使用
如果版本仍在测试，可以勾选 Set as a pre-release。预发布适合 beta、rc、preview 等版本，提醒用户这不是稳定版。比如 v2.0.0-beta.1 可以用于收集反馈，但不建议普通用户直接升级。
预发布说明里应写清风险：是否可能有破坏性变化，配置是否兼容，能否回退。越是涉及数据迁移和配置变更，越要谨慎标注。
六、发布后如何修改
Release 发布后仍可以编辑。进入 Releases，找到对应版本，点击 Edit，可以修改说明、补充附件或标记为 Latest。若发现附件错误，应尽快替换并在说明中标注。不要悄悄替换重要文件而不说明，否则用户无法判断下载内容是否变化。
如果版本存在严重问题，可以发布修复版本，而不是频繁修改同一个 Tag。Tag 一旦对外发布，最好保持稳定。确实需要移动 Tag 时，应在项目说明中解释原因。
七、让版本说明更像用户能读懂的更新记录
很多项目的 Release Notes 直接复制提交记录，例如 fix bug、update deps、change style。这类写法对维护者有意义，但对真正下载版本的人帮助有限。更好的做法是把提交记录翻译成结果：修复了哪个场景下的问题，新增能力解决了什么需求，升级后是否需要修改配置。比如“修复上传失败”可以写成“修复大文件上传时偶发中断的问题，尤其影响网络不稳定环境下的批量上传”。
如果版本涉及界面变化，说明中可以加入截图或简短说明。用户升级前往往关心入口是否变化、旧功能是否还在、数据是否兼容。把这些问题提前回答清楚，可以减少 Issue 区的重复提问。对站长工具、插件、主题、脚本类项目来说，版本说明越具体，用户越容易判断是否应该立即升级。
八、安装包和源码包不要混淆
GitHub 自动生成的 Source code 压缩包只是该 Tag 对应的源码快照，并不包含你本地构建出来的可执行文件。如果项目是前端主题、WordPress 插件、桌面工具或命令行程序，用户通常需要的是打包后的产物。发布时应把最终可用文件作为附件上传，并在说明里告诉用户下载哪个文件。
例如 WordPress 插件应提供可直接上传后台的 zip，桌面软件应区分 Windows、macOS、Linux，命令行工具应说明是否需要额外运行安装命令。如果只让用户下载源码再自行构建，会显著提高使用门槛，也容易造成“我下载后不能用”的误解。
九、发布节奏也会影响项目可信度
Release 不必每次提交都发，但也不能长期没有版本。频繁发布会让用户疲于升级，过久不发布则会让稳定功能无法被清晰标记。小型开源项目可以在完成一组功能或修复后发布；工具类项目可以在关键 Bug 修复后及时发补丁版本；有破坏性变化时应单独发布大版本并写清迁移方法。
如果项目还在早期迭代，可以用 0.x 版本表达不稳定状态。等 API、配置和主要功能稳定后，再发布 1.0.0。版本节奏本身也是项目维护态度的一部分，清楚的 Tag 和 Release 会让外部贡献者更容易参与。
