Orbit 发布版本

The Releases tab turns your git tags into a version history you can read: every tagged deployment, in order, with its commit, its author, its status and a link straight to the tag in your repository.

Releases 标签页将你的 git 标签转化为可读的版本历史记录：每个已标记的部署，按顺序排列，包含其提交、作者、状态，以及指向你仓库中该标签的链接。

Releases 的位置

打开 Orbit，点击项目，然后在项目标签栏的 Deployments 组下选择 Releases。该页面标题为 Releases，描述为基于标签的部署：当 git 标签匹配你的标签模式时，就会创建一个发布版本。

相邻的 Deployments 标签页列出每个构建，无论是否已标记。Releases 是过滤后的视图：仅显示你标记为版本的那些。

设置标签模式

Releases 从一个模式开始。打开 Settings，找到 Git tag deploys 卡片，然后输入一个 glob，例如 v* 或 release-*。如果留空，标签部署将被完全禁用，这就是该字段的占位符显示 v* (disabled) 的原因。

设置好模式后，推送匹配的标签会部署到生产环境并将结果记录为一个发布版本。如果没有设置，Releases 标签页会显示一个空状态，提示你推送标签并在 Settings 中设置模式。

标签模式为你提供了一条第二条、明确的生产部署路径，与推送到生产分支并行。希望部署成为明确行为而非合并副作用的团队通常会关闭分支自动部署，仅通过标签驱动生产。

切割发布版本

从你这一端的整个流程包括两个 git 命令：

git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0

Orbit 接收标签，将其与你的模式匹配，将已标记的提交部署到生产环境，并将其记录为一个发布版本。它会出现在此标签页上，显示 Building 徽章，当部署完成时移动到 Deployed，或在构建出错时显示 Failed。

使用带注解的标签而不是轻量级标签。带注解的标签包含消息、作者和日期，这些信息都会显示在发布版本上。

为现有部署添加标签

你不必推送 git 标签来获得发布版本。任何部署都可以从其详细信息页面进行标记，形如版本号的标签会在此处被识别。

版本形状的标签是指类似 1.4、1.4.0、v1.4.0 或 v2.0.0-rc1 的标签。其他任何内容都保持为普通部署标签，不会创建发布版本条目。

这是解决以下情况的办法：发布版本在你设置模式前已发出，或热修复是手动部署的，你希望它出现在版本历史中。

读取发布版本

每个发布版本行显示：

标签，作为发布版本的标题。
提交及其信息。
作者，显示为by name。
部署的环境，按类型用颜色标记。
状态徽章：Deployed、Building 或 Failed。
指向你仓库中该标签的 View on 链接。
指向底层部署的链接。

View on 链接根据供应商指向正确的位置：GitHub 上的发布版本页面、GitLab 上的标签页面，或 Bitbucket 上该标签处的源代码。

发布说明

如果你在仓库中为某个标签发布发布版本说明，这些说明会被拉取并附加到部署，因此 Releases 标签页会显示你在仓库中编写的相同文本，而不是让你维护两份副本。

这使得仓库成为编写发布说明的唯一地点。在你的贡献者已经所在的地方编写一次，它们就会显示在这里。

每个标签一个发布版本

列表按标签去重：如果一个标签被部署过多次，例如因为第一次构建失败而你重试了，则仅显示该标签最近的部署。

顶部的计数器给出总数，列表涵盖最近已标记部署的一个大范围窗口，而不是项目的整个历史。

好好使用 Releases

在合并时标记，不要在分支上标记。 标记实际上在你生产分支上的提交。标记一个未被合并的功能分支提交会生成一个与 main 上的任何内容都不对应的发布版本。

使用语义版本。 它们排序正确，被识别为版本形状，每个人都已经知道如何阅读它们。

永远不要移动标签。 将现有标签重新指向新提交意味着此列表中的发布版本和仓库中的标签现在在已发布的内容上产生分歧。改为切割一个新的补丁版本。

标签推送如果匹配你的模式会直接部署到生产环境。这不会绕过任何其他内容：部署锁、批准要求和冻结窗口仍然按配置应用。但这确实意味着意外推送的标签是一个生产部署，而不是草稿。有关可用的门控，请参阅 Deploying Your Project。

回滚发布版本

发布版本是部署，所以回滚一个发布版本就是普通的回滚流程：打开部署并恢复前一个成功的部署。请参阅 Rolling Back a Deployment。

之后，为修复版本切割一个新标签，而不是删除坏的标签。失败的发布版本留在历史中是有用的信息，不是混乱。

故障排除

推送了标签但没有出现发布版本。 检查 Settings 中的模式，然后检查标签是否真的到达了远程。git push origin v1.4.0 推送一个标签；单独 git push 不推送任何内容。

发布版本显示 Failed。 构建失败，就像分支推送时一样。打开部署并读取日志：Reading Build Logs。

View on 链接缺失。 项目没有已连接的仓库，所以没有地方可以链接。连接一个：请参阅 Connecting a GitHub Repository。

手动标记的部署未列出。 该标签不是版本形状。将其重命名为类似 v1.4.0 的内容。

发布说明为空。 说明是从你仓库中的已发布发布版本拉取的。没有发布对象的裸标签没有可拉取的说明。

接下来去哪里

Deploying Your Project 了解完整的部署周期及其门控。
Rolling Back a Deployment 当发布版本出现问题时。
Orbit Timeline Annotations 记录发布版本的变更。