GitHub 仓库怎么创建并发布 Release：标签入口、变更说明与发布状态核对

代码合并到默认分支后，团队往往还差一个对外可识别的版本节点：别人需要知道下载哪个版本、这一版改了什么、对应哪一个提交。GitHub 网页端的 Release 流程正好把这几件事放在一起完成。下面只做一件事：从一个仓库的 Releases 入口创建一个带新标签的 Release，发布后再回到页面核对结果。

什么时候应该用 Release，而不是只推一个 tag

Git tag 只是代码历史上的标记，Release 则是在这个标记之上补充了面向使用者的说明和下载入口。GitHub 官方文档也把 Release 描述为打包软件、发布说明和二进制文件的版本单元。

这次演示不上传二进制附件，避免把“发布版本”和“构建产物上传”混成两个任务。你只需要一个自己有写权限的 GitHub 仓库，以及一个尚未占用的版本号，例如 v1.4.0。

按网页路径创建并发布版本

步骤一：从仓库主页进入 Releases

1. 打开目标仓库主页，在文件列表右侧找到 Releases。
2. 点击 Releases，进入版本列表；再点击页面顶部的 Draft a new release。

入口状态的关键不是页面长什么样，而是你已经进入目标仓库的版本区，而不是个人主页或代码分支列表。

步骤二：选择标签并填写版本标题

1. 在 Choose a tag 下拉框中输入版本号。如果这个标签还不存在，选择 Create new tag，并确认 Target 指向包含本次代码的分支。
2. 在 Release title 中填写人类可读的版本名，例如 v1.4.0：配置加载改进。
3. 在说明区域写清用户真正关心的变化；如果页面提供 Generate release notes，先生成草稿，再删掉与本次版本无关的条目。

这里最容易出错的是标签和目标分支。标签一旦指向错误提交，后面即使标题写得很准确，下载到的源码仍然不是你要发布的那一版。

步骤三：检查发布选项并点击 Publish release

1. 从头读一遍标题和说明，确认版本号、变更范围和破坏性变化没有写反。
2. 如果版本还不适合生产使用，勾选 This is a pre-release；正式版本不要误勾这个选项。
3. 确认页面底部的目标按钮是 Publish release，点击后等待页面跳转到已发布的 Release。

成功状态通常表现为：页面从编辑表单回到 Release 详情，能看到版本标题、tag 和发布时间；如果仍停留在草稿表单，说明你保存的是 draft，还没有完成公开发布。

发布后用三个字段做最终核对

回到仓库主页的 Releases 页面，逐项确认：

• 标题：显示的是本次版本名，而不是默认的 tag 文本。
• Tag：版本号与创建时填写的 tag 完全一致，并且点开后指向预期代码点位。
• 状态：页面没有 Draft 标记；如果设置了预发布，应该明确显示 Pre-release。

GitHub 还会自动提供该 tag 对应源码的 ZIP 和 tarball 下载链接。需要给 README 或更新公告引用时，可以使用仓库的 /releases/latest 路径，但前提是这次 Release 确实被标记为最新版本。

常见问题与回退处理

为什么找不到 Draft a new release？

先确认当前账号对仓库有写权限，再确认你进入的是仓库的 Releases 页面；只有查看权限时通常只能浏览，不能管理 Release。

标签已经存在还能发布吗？

可以选择已有标签创建 Release，但不要把它误当成“重新发布当前分支”。先打开标签对应的提交，确认代码点位正确；若需要发布另一份代码，应该创建新的版本标签。

说明写错了需要删除整个版本吗？

不必。进入 Release 详情后使用编辑入口修改标题或说明；如果发现 tag 指向错误提交，则先暂停传播链接，再评估是否重新创建正确标签和 Release，避免让使用者下载错版本。

完成标准

这次任务完成的标志是：Release 页面显示正确的版本标题，tag 指向预期提交，说明内容经过人工核对，页面没有 Draft 标记；如果仓库有预发布策略，Pre-release 状态也与版本计划一致。做到这四点，别人拿到链接时才知道该下载什么、这版改了什么。