查看和合并 Bicep 更改

  • 4 分钟

你已了解如何使用功能分支以及如何应用分支保护，以确保在合并更改之前查看更改。 现在，你需要执行一致的过程，在合并更改之前提出并查看更改。

在本单元中，你将了解有关拉取请求的详细信息，包括如何创建和使用拉取请求。 你还将了解如何使用拉取请求查看 Bicep 代码。

拉取请求

拉取请求是一个由功能的开发人员向主分支的维护者发出的请求。 要求维护者将所做的更改拉取到存储库的主分支中。

拉取请求和分支保护

配置分支保护时，可以要求代码所有者评审拉取请求。 例如，可以将项目负责人作为所有拉取请求的评审者，也可以指定一定数量的用户必须评审每个拉取请求。

拉取请求和分支策略

配置分支策略时，可以要求特定人员或一组人员查看拉取请求。 例如，可以添加项目负责人来作为所有拉取请求的评审者，也可以指定一定数量的用户必须评审每个拉取请求。

还可以要求每个拉取请求都链接到工作项。 通过使用此配置，既可以跟踪包含功能请求的工作项，又可以跟踪实现更改的代码，还涉及部署到生产环境。

创建拉取请求

可以通过使用 GitHub Web 界面来创建拉取请求。 选择在其中进行了更改的源分支，以及通常是存储库的主分支的目标分支。

可以通过使用 Azure DevOps Web 界面来创建拉取请求。 选择在其中进行了更改的源分支，以及通常是存储库的主分支的目标分支。

创建拉取请求时，需要为其命名。 最佳做法是让拉取请求名称清晰易懂。 这种做法可帮助你的团队成员了解他们被要求查看的内容的上下文。 如果他们具有不同的专业领域，则一个好名称可以帮助他们找到其可提供有意义的反馈的拉取请求，并跳过与其不相关的拉取请求。

此外，拉取请求名称通常会成为 Git 存储库历史记录的一部分，因此最好是确保当有人回顾该历史记录时能够理解这些名称。

还可以为拉取请求指定说明。 可以提及特定人员或参考说明中的问题。 许多团队会为拉取请求说明创建标准化模板，这样才能清楚地知道每个更改。

还可以为拉取请求指定说明。 你可以提及特定人员或参考说明中的工作项。 许多团队会为拉取请求说明创建标准化模板，这样才能清楚地知道每个更改。

创建拉取请求时，可以邀请人员查看更改。

有时，创建拉取请求只是为了从同事那里获得反馈。 在这些情况下，可以指定拉取请求是草稿。 审阅者将知道你仍在处理所做的更改。 审阅者仍可提供反馈，但很明显，更改尚未准备好进行合并。 如果对更改感到满意，则可以删除草稿状态。

即使在创建拉取请求后，也可以继续更改功能分支上的代码。 这些更改将成为拉取请求的一部分。

查看拉取请求

查看拉取请求时，可以查看所有更改。 你可以对整个拉取请求进行评论，也可以仅对已更改文件的特定部分进行评论。 拉取请求作者可以对评论做出响应，其他审阅者可以参与讨论。 这些评论功能使协作处理拉取请求成为一种交互式的体验。

查看 Bicep 代码时，请查找以下关键元素：

  • 文件是否可部署？ 在合并 Bicep 代码之前对其进行部署和测试。 确保没有 Linter 警告且 Azure 部署成功。 在将来的 Microsoft Learn 模块中，你将了解自动部署和验证更改的方法。
  • Bicep 代码是否清晰易懂？ 你团队中的每个人务必都要了解 Bicep 代码。 查看拉取请求中的 Bicep 文件时，请确保了解每个更改的确切用途。 变量和参数的名称是否正确？ 是否已使用注释来解释代码的任何复杂部分？
  • 更改是否已完成？ 如果此拉取请求表示更多工作中的一部分，请确保在合并和部署此更改时你的环境将起作用。 例如，如果拉取请求重新配置 Azure 资源来准备以后的更改，请验证该资源在整个过程中是否继续正常工作。 如果拉取请求添加尚不需要的新 Azure 资源，请考虑是否应暂时添加条件，以便在需要时才部署资源。
  • 更改是否遵循 Bicep 最佳做法？ 在其他 Microsoft Learn 模块中，你已了解好的 Bicep 代码的元素。 确保查看的代码遵循相同的最佳做法。
  • 更改是否符合说明？ 最佳做法是拉取请求包括描述性标题。 许多团队还要求拉取请求包括对更改及其用途的说明。 检查对 Bicep 代码的更改是否匹配拉取请求详细信息。 如果拉取请求作者已链接到工作项或问题，请验证拉取请求中的更改是否满足工作项定义的成功条件。

完成拉取请求

拉取请求获得批准后，即可完成。 这意味着拉取请求的内容将合并到主分支中。

在某些团队中，拉取请求的创建者还应完成该请求。 此过程有助于确保作者控制何时进行合并，并可用于监视任何自动部署。 在其他团队中，审批者会完成拉取请求。 你的团队应决定合并拉取请求的人员和时间。

在某些团队中，拉取请求的创建者还应完成该请求。 此过程有助于确保作者控制何时进行合并，并可用于监视任何自动部署。 在其他团队中，审批者会完成拉取请求。 你甚至可以使用 Azure DevOps 在满足审批条件时自动完成拉取请求。 你的团队应决定合并拉取请求的人员和时间。

团队的过程

开始使用功能分支和拉取请求之后，团队的过程可能会更改为如下所示的内容：

  1. 团队成员克隆共享存储库。

  2. 他们在自己的存储库本地副本中的分支上进行本地更改。

  3. 完成更改后，他们会将其本地分支推送到共享存储库。

  4. 在共享存储库中，他们创建一个拉取请求，将分支合并到主分支。

    其他团队成员将查看所做的更改。 满足这些条件后，他们批准拉取请求并合并到共享存储库的主分支。

  5. 他们删除共享存储库及其存储库的本地副本中的分支。

    在某些情况下，远程存储库的推送会触发自动化管道来验证、测试和部署代码。 你将在其他 Microsoft Learn 模块中了解有关管道的详细信息。

下图对此修改后的过程进行了说明。

图中显示了进行本地更改、打开拉取请求、删除本地分支和触发管道的过程。