查看和合并 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. 在共享存储库中，他们创建一个拉取请求，将分支合并到 main。

    其他团队成员将查看所做的更改。 当他们满意后，会批准拉取请求，并将其合并到共享库的主分支。

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

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

下图演示了此修订的过程。

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