什么是基于发布的工作流？

  • 8 分钟

本文将介绍如何使用 GitHub 创建基于发布的工作流。

什么是基于发布的工作流？

“基于发布的工作流”是一组侧重于发布软件的模式和策略。 虽然这一概念对于开发团队来说可能是一个明确的目标，但这种观点的价值会更微妙。 本单元讨论它如何驱动发布周期的三个不同部分：管理项目、选择分支策略以及向客户发布。

使用 GitHub 项目板规划工作

从规划的角度，以发布为中心意味着发行划分为不同的迭代，以生成新的版本。 这些迭代通常称为“冲刺 (sprint)”，并在有时间限制的大致相等的时间段内，产生增量更改。 其他团队更喜欢将整个发布版本打包到可以持续几个月或更长时间的单个迭代中。 在 GitHub 中，这些迭代作为“项目”进行管理。

项目的主要特征在于它的“板”。 板是迭代记录的中心计划，包含所有要解决的卡片。 卡片可以用于表示问题、拉取请求，甚至通用注释。

版本 1.0 跟踪器的屏幕截图。

默认情况下，每张卡片从“待处理”列开始，并在工作开始后移动到“正在进行中”，然后以“已完成”结束。 你可以自定义这些列、添加其他列或应用自动化来移动这些卡片及其属性，以适合团队的流程。

详细了解管理项目板。

卡片的项目状态可以在存储库中集成。 例如，将卡片从“待处理”拖动到“正在进行中”将更改其状态，还会更新项目标题旁边的可视指示器。 绿色部分指示标记为“已完成”的卡片部分，而紫色用于指示“正在进行中”的卡片。 剩余空间表示尚未开始的卡片数量。 除了在板周围拖动卡片，还可以从主视图更新它们。

移动项目卡的屏幕截图。

使用项目板时，所有利益干系人都可轻松了解项目的状态和速度。 你还可以为单独的用户或为组织拥有的存储库集合创建项目板。

详细了解使用项目板跟踪工作进度。

跟踪特定里程碑

对于团队或团队子集，GitHub 提供了里程碑跟踪。

GitHub 项目板的屏幕截图。

里程碑与项目跟踪类似，因为都强调优先完成问题和拉取请求。 但是，项目可能侧重于团队的流程，而里程碑侧重于产品。

已准备好进行首次部署的站点的屏幕截图。

详细了解使用里程碑跟踪工作进度。

选择分支策略

如果存储库具有多名开发人员并行工作，则需要一个定义完善的分支策略。 如果在项目早期确定一个统一方法，则可避免在团队和代码库缩放时产生混乱和挫折。

GitHub 流

除提供协作软件开发平台外，GitHub 还提供了一个既定工作流，旨在优化其各种功能的使用。 尽管 GitHub 几乎可以处理任何软件开发过程，但如果你的团队尚未确定一个流程，则建议你考虑 GitHub 流。

使用长期分支

“长期分支”是永远不会删除的 Git 分支。 一些团队选择完全避开它们，而倾向于短期功能和 Bug 修复分支。 对于这些团队来说，任何工作量的目标都是生成一个拉取请求，将他们的工作合并回 main。 此方法对于永远不需要回头处理的项目（如永不支持早期版本的第一方 Web 应用程序）非常有效。

但是，在某些情况下，长期分支更符合团队的最佳利益。 长期分支的最常见情况是，产品具有多个需要长期支持的版本。 如果团队需要规划此承诺，存储库应遵循标准约定，如 release-v1.0、release-v2.0 等。 这些分支还应在 GitHub 中标记为受保护，以便控制写入访问，避免被意外删除。

团队仍应将 main 作为根分支，并在上游合并其发布分支更改，只要它们适应项目的未来。 到时，release-v3.0 应基于 main，以便 release-v2.0 维护工作不会让存储库复杂化。

维护长期分支

假设 Bug 修复已合并到 release-v2.0 分支中，然后再次在上游合并到 main。 后来发现，此 Bug 也存在于 release-v1.0 分支中，需要为仍在使用该版本的客户向后移植修补程序。 向后移植此修补程序的最佳方式是什么？

将 main 分支向下合并到 release-v1.0 不是一个可行的选择，因为它将包含大量不打算成为该版本的一部分的提交。 出于相同的原因，不能选择将 release-v1.0 变基到当前 main 提交。

一种替代选项是，手动重新实现 release-v1.0 分支的修复，但这种方法需要大量返工，并且不能跨多个版本很好地缩放。 但是，Git 确实以其 cherry-pick 命令的形式提供此问题的自动化解决方法。

什么是 Git cherry-pick 命令？

git cherry-pick 命令使你可以将特定提交从一个分支应用到另一个分支。 它只需迭代所选提交，并将它们作为新提交应用于目标分支。 如有需要，开发人员可以在完成后向移植之前合并任何冲突。

详细了解 Git cherry-pick。

向使用者发布

当产品版本准备好发布时，GitHub 将简化打包和通知使用者的过程。

创建 GitHub 版本的屏幕截图。

创建版本与填写表单一样简单：

  • 输入要应用的 Git 标记，该标记应遵循语义化版本控制（如 v1.0.2）。 GitHub 管理创建指定的 Git 标记的过程。
  • 为你的版本输入名称。 一些常见做法是：
    • 使用描述性名称
    • 使用 Git 版本
    • 简要概述该版本自上一版本以来发生的更改
    • 使用代码名称或随机短语
  • 提供发行说明。 可以通过 Release Drafter 应用自动实现此任务，该应用分析自上一版本以来的更改，并包括关联的拉取请求标题。
  • 如果要提供作为发布的一部分的文件（如预构建的安装程序），可将它们拖放到窗体上。 不需要打包源，因为 GitHub 会自动为你处理。
  • 通过选中该框指示版本是否是预发行版本。 此指示可帮助客户在需要时避免使用预发行版本。

查看 GitHub 版本的屏幕截图。

当有版本发布后，查看存储库的所有人均会收到通知。

详细了解 GitHub 版本。