GitHub 流的组件

  • 8 分钟

在本单元中，我们将查看 GitHub 流的以下组件：

  • 分支
  • 提交
  • 拉取请求
  • GitHub 流
  • Git 流

GitHub Flow 的组件

在进入特定于 GitHub 的工作流之前，了解 GitHub Flow 直接构建在 Git 的基础概念上会很有帮助。

Git 提供了一段时间内跟踪和管理代码中的更改的工具。 GitHub 通过更轻松地将这些工具与分支、提交、拉取请求和可视化界面等功能一起使用来构建。 首先，让我们看看这些概念在 GitHub 中的工作原理。

分支是什么

在最后一部分中，我们在存储库中创建了一个新文件和一个新分支。

分支是 GitHub 体验的重要组成部分。 它们允许你进行更改，而不会影响默认分支。

分支是试验新功能或修补程序的安全场所。 如果犯了错误，可以恢复更改或推送其他更改来修复错误。 在合并分支之前，更改不会在默认分支上更新。

注意

或者，也可以创建一个新分支，并在终端中使用 git 将其签出。 命令将如下所示：git checkout -b newBranchName

什么是提交

在上一单元中，你通过推送某个提交将新文件添加到了存储库中。 让我们简单回顾一下什么是提交。

“提交”是分支上对一个或多个文件的更改。 无论是通过命令行还是直接在 GitHub 的 Web 界面中进行，每个提交都由唯一 ID、时间戳和参与者跟踪。 提交为查看文件或链接项（如问题或拉取请求）的历史记录的任何人提供了清晰的审核线索。

可以在终端中使用 Git 创建提交，

git commit -m "Add a helpful commit message"

向主分支进行的 GitHub 提交列表的屏幕截图。

在 git 存储库中，文件在经历版本控制过程时可以以多种有效状态存在。 Git 存储库中文件的主要状态包括：未跟踪和已跟踪。

未跟踪：文件尚不是 Git 存储库的一部分时的初始状态。 Git 不知道其存在。

已跟踪：跟踪的文件是 Git 正在主动监视的文件。 它可能会处于以下任一子状态：

  • 未修改：已在跟踪文件，但自上次提交以来未对其进行修改。
  • 已修改：文件自上次提交以来已发生更改，但尚未暂存这些更改进行下一次提交。
  • 已暂存：已修改文件，并且已将更改添加到暂存区域（也称为索引）。 已准备好提交这些更改。
  • 已提交：文件位于存储库的数据库中。 它表示文件的最新提交版本。

这些状态可帮助团队了解每个文件的状态及其在版本控制过程中的位置。

拉取请求是什么？

“拉取请求”是用于表示一个分支的提交已准备好合并到另一个分支的机制。

提交拉取请求的团队成员会请求一名或多名审阅者验证代码并批准合并。 这些审阅者可以对更改发表评论、添加自己的更改或使用拉取请求本身进行进一步讨论。

GitHub 还支持 草稿拉取请求，使你能够打开尚未准备好审阅的拉取请求。

更改获得批准后（如果需要审批），拉取请求的源分支（比较分支）会合并到基分支中。

拉取请求和拉取请求中的注释的屏幕截图。

现在，你已了解分支、提交和拉取请求的工作原理，接下来让我们逐步了解它们如何在 GitHub Flow 中组合在一起。

GitHub 流

显示 GitHub 流的可视表示形式（采用线性格式）的屏幕截图，其中包括新的分支、提交、拉取请求，以及按该顺序将更改合并回 main。

GitHub 流是一个简单的工作流，可帮助你安全地进行更改和共享更改。 它非常适合使用分支、拉取请求和合并来尝试想法并与团队协作。

注意

GitHub 流是几个常用工作流之一。 其他包括 Git 流和基于中继的开发。

现在我们已经了解了 GitHub 的基础知识，接下来可以逐步了解 GitHub 流及其组件。

  1. 首先创建分支，以便更改、功能或修补程序不会影响主分支。
  2. 接下来，在分支中进行更新。 如果工作流支持它，则可以在此分支部署更改，以在合并之前对其进行测试。
  3. 现在，打开拉取请求以邀请反馈并开始评审。
  4. 然后，根据团队的反馈查看评论并进行任何必要的更新。
  5. 最后，在对更改有信心后，获得批准并将拉取请求合并到主分支。
  6. 之后，请删除分支以保持存储库干净，并避免使用过时的分支。

Git 流

说明 Git 流工作流的示意图，其中包含功能分支、开发、发布分支、修补程序和主节点的并行通道。它演示了如何将功能合并到开发中、从开发创建发布分支、修补程序从主节点分支进行分支，并且所有更改最终合并回主服务器并使用标记版本进行开发。

虽然 GitHub Flow 是专为持续交付设计的轻型工作流， 但 Git 流 是一种结构化的分支模型，通常用于发布驱动环境。 Git 流已超过 GitHub Flow，你仍会看到使用的术语 master 而不是 main 默认分支。

Git 流分支类型

Git 流使用多个长期和临时分支：

  • master：始终反映生产就绪代码。
  • develop：包含下一个版本的最新开发工作。
  • feature/*：用于创建新功能;完成时分支 develop 并合并回来。
  • release/*：从中准备新的生产版本 develop;允许最终测试和次要 bug 修复。
  • 修补程序/*：用于快速修补生产问题;分支自 master.

Git 流流程的工作原理

  1. 开发人员从develop中创建功能分支以生成新功能。
  2. 在发布时，会从develop中创建发布分支。 这会隔离发布准备工作，以便开发可以持续不间断。
  3. Bug 修复可以添加到发布分支，但主要功能应等待将来的版本。
  4. 准备就绪后，发布分支将合并并 master 标记有版本号。 GitHub 可以使用这些标记来帮助你生成发行说明。
  5. 应将同一发布分支合并回 develop 以使其保持同步。
  6. 如果出现关键的生产 bug，则会从master中创建修补程序分支。 修复后，它将合并到这两个和 master 中 develop。

何时使用 Git 流

  • 最适合具有计划或版本控制版本的项目
  • 如果维护 多个生产版本 （例如长期支持分支），则很有帮助
  • 非常适合 较慢、结构化更高的开发周期 （例如企业或受监管环境）
  • 由于其他分支管理，被认为比 GitHub Flow 更“重量级”

注意

Git 流假定合并提交用于集成分支。 使用 rebase 或 squash 合并可能会干扰其分支结构和历史记录跟踪。

对于许多使用 GitHub 的团队，GitHub Flow 更简单、更快。 但是，如果你的团队重视可预测性并需要更多的发布规划，则 Git 流可能更合适。

祝贺！ 你刚刚浏览了完整的 GitHub Flow，并探索了 Git 流如何为发布驱动项目提供结构化替代方案。

让我们转到下一部分，了解问题和讨论之间的差异。