针对主要更改的 GitHub 参与工作流
概述
此工作流适合需要做出主要更改或将经常向存储库投稿的参与者。 经常投稿的参与者通常会不断(持续时间长)做出更改,这些更改将经历多个周期(构建/验证/分段)或在签发和合并拉取请求之前跨越多日。
术语
在开始之前,我们先看看此工作流中所使用的 Git/GitHub 术语。
如果您不熟悉 Git 和 GitHub 概念(如存储库或分支),请先查看 Git 和 GitHub 基础知识。
工作流
在此工作流中,更改重复循环流入。 从您设备的本地存储库开始,它们将流回您的 GitHub 分支存储库,进入主 GitHub 存储库,并在您合并其他参与者所做的更改时再次从本地返回。
使用 GitHub 流
从 Git 和 GitHub 基础知识回想 Git 存储库包含一个主分支,外加尚未集成到主分支中的任何其他正在运行的分支。 每当您想引入一组逻辑上相关的更改时,最佳实践是创建 工作分支 以通过工作流管理您所做的更改。 我们在此将它称为工作分支是因为直到可将更改集成回主分支中为止,它都是一个用于迭代/细化更改的工作区。
通过隔离特定分支的相关更改,您可以单独控制和引入这些更改,将这些更改定位到发布周期中的特定发布时间。 实际上,根据您所从事的工作类型,您可以轻松地在存储库中使用多个工作分支。 在同一时间使用多个分支并不罕见,各个分支代表各个不同的项目。
接下来,在本地存储库中创建一个新的工作分支,以获取您提议的更改。 每个 git 客户端各不相同,因此请咨询首选客户端的帮助。 您可以在 GitHub 流的 GitHub 指南中查看该过程的概述。
拉取请求处理
您可以提交建议的更改,方法是通过将它们捆绑在添加到目标存储库的 PR 队列的新拉取请求 (PR) 中。 拉取请求会启用 GitHub 的协作模型,方法是请求将工作分支的更改拉入并合并到另一个分支。 在大多数情况下,这另一个分支就是主存储库中的默认/主分支。
验证
在将拉取请求合并到目标分支之前,可能需要通过一个或多个 PR 验证过程。 验证过程可能会有所不同,具体取决于建议的更改范围和目标存储库的规则。 提交拉取请求后,您可以审核内容,并在适当时将其合并到主存储库中。
审核和注销
After all PR processing is completed, you should review the results (PR comments, preview URLs, etc.) to determine if additional changes to its files are required before you sign off for merging. 在 PR 审核人员审核了您的拉取请求后,如果在合并之前具有待解决的问题,他们也可以通过添加注释的方式提供反馈。
当拉取请求没有问题并签发后,系统会将您的更改合并回父分支,并且关闭拉取请求。
发布
请记住,您的拉取请求必须先由 PR 审核人员合并,然后才能将更改包含在下一个预定发布运行中。 通常,审核人员会按提交顺序审核/合并拉取请求。 如果需要先合并您的拉取请求才能将其包含在特定的发布运行中,您需要提前与 PR 审核人员展开合作,以确保在发布之前进行合并。