分支保护规则怎么设置：Git 项目安全必备操作

分支保护规则怎么设置

团队协作开发中，主分支被误删或随意推送代码的情况时有发生。前几天同事小李手滑，在没经过 Code Review 的情况下直接往 main 分支提交了一段有问题的代码，导致线上服务差点崩溃。这种事一旦频繁发生，项目稳定性就很难保障。解决办法其实很简单——设置分支保护规则。

以 GitHub 为例，进入仓库页面，点击「Settings」→「Branches」，在「Branch protection rules」区域点击「Add rule」。输入要保护的分支名称，比如 main 或 release/* 这类通配模式。

关键选项说明

勾选「Require a pull request before merging」能强制所有人通过 PR 合并代码，避免直接推送。再勾上「Require approvals」，可以设定至少需要 1 名或多名审核人同意才能合并。

如果担心历史记录被篡改，启用「Require status checks to pass before merging」很重要。这样 CI/CD 流程跑不通的话，PR 就没法合进去。像单元测试、代码格式检查这些关键步骤就不会被跳过。

还有一个实用选项是「Restrict who can push to matching branches」。只有指定的管理员或部署账号才能直接推送到受保护分支，普通开发者只能走 PR 流程。

GitLab 上的设置方式

在 GitLab 中，路径类似：「Settings」→「Repository」→「Protected Branches」。选择目标分支，比如 main，然后设置谁可以推送、谁可以合并。通常把「Allowed to merge」设为开发者角色以上，而「Allowed to push」只留给运维或高级工程师。

也可以配置合并前必须通过流水线（CI/CD pipeline），这和 GitHub 的状态检查功能差不多。一旦开启，任何未通过测试的 MR（Merge Request）都无法合入。

简单的 YAML 配置示例

有些平台支持用配置文件定义保护策略。例如在 .github/branch-protection.yml 中写：

rules:
  - name: main
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
        dismiss_stale_reviews: true
      required_status_checks:
        strict: true
        contexts:
          - "ci/circleci: test"
      restrictions:
        users: []
        teams: [dev-ops, lead-dev]
      enforce_admins: true

这类配置可以用自动化脚本批量部署到多个仓库，适合管理几十个微服务项目的场景。

别等到出问题才想起加保护。新项目初始化后第一时间就把主干分支锁好，让流程规范从第一天就开始运行。