简介
当你处理 Bicep 代码时，Git 存储库的主分支成为事实来源。 主分支合并整个团队的最新更改，通常反映 Azure 环境的状态。
重要的是，合并到存储库的主分支的更改要经过评审。 在本模块中，你将了解如何使用其他分支和拉取请求评审来保护主分支。
示例方案
假设你负责在一家玩具公司部署和配置 Azure 基础结构。 你的团队正在不断发展，因此，跟踪每个人所做的所有更改也越来越困难。
最近，团队的一名新成员意外地更改了存储库主分支上的一个重要的 Bicep 文件。 此更改导致组织的生产环境出现问题。 你和你的团队讨论后决定，是时候开始在合并和部署代码更改之前进行评审了。
现在，你需要对网站处理订单的方式进行更改。 你需要添加一个消息队列，以便在客户每次下达玩具订单时，网站都可以发布消息。 由另一个团队生成的后端系统将提取这些消息，并稍后处理订单。 你需要确保在其他团队准备就绪之前，不会开始向队列发送消息。
你确定这是尝试新流程的绝佳机会。 你将使用拉取请求来控制 Bicep 更改的合并。 代码将由作者编写，由审阅者评审，然后在将其部署到 Azure 之前合并到 Git 存储库。
我们将执行哪些操作？
在本模块中，你将了解如何通过拉取请求强制执行变更控制流程，从而保护主分支上的代码。 你将了解分支策略，以及如何防止你的团队对主分支进行更改，除非他们遵循了正确的流程。 你还将了解如何使用拉取请求来查看代码。
主要目标是什么？
完成本模块后，你将能够为自己的 Bicep 代码使用分支策略。 你还将了解如何创建、评审和合并拉取请求。 你将了解在评审 Bicep 代码的拉取请求时需要注意的重要因素。