😀 前言：
在 GitHub 上设置main分支保护（Branch Protection）可以防止代码被直接修改，确保通过 Pull Request 审核、CI 通过等流程后再合并，这是多人协作项目的最佳实践之一
✅ 一步步操作指南（图形界面）
🔧 1. 打开你的 GitHub 仓库
- 登录 GitHub，进入你要设置的仓库
- 点击上方的
Settings（⚙️ 设置）
🛡️ 2. 进入分支保护设置
- 在侧边栏点击
Branches - 在Branch protection rules区域点击按钮
Add branch rules
✍️ 3. 编写规则
在出现的Rulesets/New branch rules中填入规则：
- Ruleset Name : 随便填，可以写 default
- Target branches :
Add taget按钮 →Include default branch(如果没做过特别设置，就是仓库的main或者master分支),同样也支持通配符，比如release/*或保护所有分支 - 选择需要的Branch rules
✍️ 4. 规则详解
- Restrict creations
限制创建分支
- 含义：只有具有 “bypass” 权限的用户才能创建匹配该规则的分支。
- 目的：防止团队成员随意创建关键分支（例如：
main、release/1.0） - 使用时机：适合发布分支或长期主干分支；团队只有 CI 或管理员允许创建。
- Restrict updates
限制更新操作
- 含义：只有具有 “bypass” 权限的用户才能更新匹配的分支。
- 目的：防止对受保护分支（如
main）进行任何 push 操作（无论是否通过 PR） - 使用时机：需要极强保护的分支，仅允许通过某种发布流程（CI/CD）写入。
- Restrict deletions
限制删除分支
- 含义：只有具有 “bypass” 权限的用户才能删除该分支。
- 目的：防止误删主干或发布分支。
- 使用时机：推荐始终启用，尤其是对
main、release/*等关键分支。
- Require linear history
要求线性历史（禁用 merge commit）
- 含义：禁止 merge commit，只允许 fast-forward 或 rebase 合并。
- 目的：保持历史记录线性、清晰。
- 使用时机：适合对提交历史有洁癖的团队，推荐搭配 Squash or Rebase Merge 使用
- Require deployments to succeed
要求部署成功后才能合并
- 含义：必须成功部署到指定环境（如 staging/prod）后，才能更新该分支。
- 目的：用于保障部署安全，特别是在 CI/CD 工作流中。
- 使用时机：适用于对部署链要求严格的生产项目主干分支
- Require signed commits
要求签名提交
- 含义：必须是通过 GPG 或 S/MIME 签名的提交。
- 目的：验证提交身份，防止伪造提交。
- 使用时机：对安全性要求较高的项目（如金融、区块链），或开源组织对身份有验证需求。
- Require a pull request before merging
强制通过 Pull Request 合并
- 含义：必须通过 PR 提交才能更新该分支，禁止直接 push。
- 目的：确保代码经过审查，不允许随意提交。
- 使用时机：强烈推荐所有正式项目启用此项。
- Require status checks to pass
要求状态检查通过
- 含义：PR 中必须通过指定的 CI 检查（如测试、lint）后才能合并。
- 目的：强制代码质量门槛，防止引入错误。
- 使用时机：只要你有自动化测试，强烈建议开启此项。
- Block force pushes
阻止强制推送
- 含义：禁止使用
git push --force对该分支进行强推。 - 目的：防止误操作导致历史被覆盖、数据丢失。
- 使用时机：所有关键分支都应启用此项，如
main、release/*。
- Require code scanning results
要求代码扫描结果
- 含义：要求启用 GitHub CodeQL 或其他静态分析工具，并提供扫描结果后才能合并。
- 目的：自动发现潜在漏洞、提升安全性。
- 使用时机：适合对安全有要求的项目，或希望强制安全审查的团队。
总结：推荐启用组合（适用于生产项目main分支）
| 选项 | 建议 |
|---|---|
| Restrict deletions | ✅ 强烈建议开启 |
| Block force pushes | ✅ 强烈建议开启 |
| Require a pull request before merging | ✅ 强烈建议开启 |
| Require status checks to pass | ✅ 有 CI 的话建议开启 |
| Require linear history | ✅（搭配 squash / rebase） |
| Require code scanning results | ⚠️ 安全性高时开启 |
| Require signed commits | ⚠️ 高安全场景使用 |
| Require deployments to succeed | ⚠️ 有完整部署流程才启用 |
| Restrict creations / updates | 🚨 谨慎使用，适合极高权限控制场景 |
📦 5. 点击 “Create” 保存规则
你的main分支现在就处于保护状态了。
🧪 效果展示
一旦设置：
- 普通开发者无法
git push origin main（会被拒绝） - 所有提交必须通过 Pull Request、并满足保护规则后才能合并
- 即便管理员也必须遵守（如果开启了“Do not allow bypass”）
🧰 高级用法（如你使用团队权限）
你可以：
- 指定只有某些 GitHub Teams 或人员可以 push
- 配合
CODEOWNERS自动分配 Reviewers - 与 GitHub Actions 搭配做自动测试 + 版本控制
🧠 如果你用的是私有部署或 GitHub Enterprise
保护规则仍然适用，只是设置界面略有不同；核心流程相同。