在主干开发模式下，代码直接合并到主干，因此保护 master/main 分支禁止直接 push 是确保稳定性的核心措施，最稳妥的方式是依托代码托管平台的分支保护规则，而不是依赖本地 Git 配置。
先说结论：开启托管平台的分支保护功能是防止误推的标准做法，适用于所有多人协作仓库。
- 适合：使用 GitHub、GitLab 或 Gitee 等托管服务的团队
- 先准备：确认你拥有仓库管理员权限
- 验收：尝试直接 push 看是否被拒绝
快速处理思路
这不是一个本地命令能解决的问题，需要在网页端配置。核心逻辑是让服务器拒绝接收针对特定分支的直接推送请求。
# 本地尝试推送时会看到类似错误
remote: error: protected branch hook declined
error: failed to push some refs to ...
主干开发模式下的保护必要性
主干开发（Trunk-Based Development）要求开发者基于主干创建短生命周期分支，并频繁合并回主干。如果允许直接 push 到主干，将带来以下风险：
- 绕过 CI/CD：直接推送可能跳过自动化测试和构建流程，导致脏代码进入生产环境。
- 代码审查缺失：没有 Pull Request 流程，同事无法进行 Code Review，增加维护成本。
- 历史覆盖风险：恶意或误操作的 force push 可能覆盖他人提交，造成代码丢失。
为什么不能用本地 Hook
部分开发者尝试使用本地 pre-push 钩子来限制推送，但这存在明显局限性：
- 可被绕过：本地钩子仅存在于当前开发环境，其他人克隆仓库后不会自动生效，且用户可使用
git push `--no-verify`绕过。 - 无法强制：只有服务器端的保护规则才能强制所有协作成员遵守，本地配置仅能约束自己。
分步处理
以下以 GitHub 和 GitLab 为例，其他平台逻辑类似。
GitHub 设置：
- 进入仓库页面，点击 Settings。
- 左侧菜单选择 Branches。
- 点击 Add branch protection rule。
- Branch name pattern 填写 master 或 main。
- 勾选 Require a pull request before merging。
- 点击 Create 保存。
GitLab 设置：
- 进入项目页面，点击 Settings -> Repository。
- 展开 Protected branches 区域。
- Branch 选择 master 或 main，Allowed to merge 和 Allowed to push 选择 Maintainers 或 No one。
- 点击 Protect。
怎么验证是否生效
配置完成后，在本地终端执行推送命令。如果保护生效，你会收到明确的拒绝错误，而不是推送成功。
git push origin master
检查点：看到 remote 返回的 protected branch 相关错误信息，且仓库网页上的代码未更新。
常见坑
1. 管理员豁免：部分平台允许管理员绕过保护规则，需检查是否勾选了包括管理员在内的强制选项（如 GitHub 的 "Include administrators"）。
2. CI/CD 账号：自动化部署账号通常需要单独授权或使用 Deploy Keys，否则流水线会因无法推送而失败。
3. 分支命名：确保保护的是实际使用的主干名称，现在不少新仓库默认使用 main 而非 master。
4. Force Push 保护：建议同时勾选 "Force push" 禁止选项，防止历史被强制覆盖。
原文链接：https://www.zjcp.cc/ask/11155.html