main分支受保护需强制PR审查、状态检查与签名验证，缺一不可；hotfix必须从main创建并带CVE/Jira编号和GPG签名；权限应按分支模式而非人员配置，确保每次merge具备不可抵赖的动作链。
main 分支不是“随便能改”的地方，而是企业代码资产的最终防线。Git 基于分支的版本控制策略本身不加密、不鉴权，但它通过**强制隔离 + 可追溯 + 不可绕过**的流程设计，把安全风险从“技术漏洞”转化为“流程可控”，这才是它对企业安全性的真正提升点。
为什么 main 分支受保护就等于生产环境更安全？
很多团队开了 main 分支的“保护规则”，但只设了“禁止直接 push”，却没配 require pull request reviews 或 require status checks —— 这等于锁了门但没装猫眼和门禁卡。
- 真实风险：开发人员用
git push --force绕过保护、CI 检查被跳过、合并前未执行git diff对比 - 关键动作必须绑定：PR 提交 → 自动触发 SAST 扫描（如 Semgrep）→ 单元测试覆盖率 ≥80% → 至少 2 名 reviewer 显式 approve
- GitLab/GitHub 的 branch protection rule 不是开关，而是一组联动策略；漏掉任意一环，
main就只是心理安慰
hotfix/* 分支怎么避免“救火变纵火”？
线上故障时，人容易慌，hotfix/* 分支常被当成“快捷通道”，结果把未经测试的修复直接合入 main，反而引入新漏洞。
Git Monitor
下载
通用Git项目监控工具，支持GitHub、GitLab、Gitee等平台。可增删仓库、检查更新、自动拉取代码并生成变更摘要。用于“监控项目”“检查更新”“添加仓库”等场景。
- 必须从
main而非develop创建：git flow hotfix start critical-db-leak，确保基线干净 - 修复提交必须含 CVE 编号或 Jira ID，例如
fix(auth): prevent token leakage in /api/login (SEC-142) - hotfix 合并后，
git tag -s v2.1.3必须带 GPG 签名，否则无法满足金融/医疗行业审计要求
分支命名和权限控制如何防止横向越权？
权限不是按“人”配，而是按“分支模式”配。比如 feature/* 允许所有人创建，但 release/* 只允许 release-manager 组写入 —— 这种细粒度控制在 GitLab 中靠 Protected Branches + Group-level permissions 实现，在 GitHub 中需配合 Custom roles。
- 常见错误：把所有分支设为 same permission level，导致 junior dev 能推
release/分支 - 推荐模式：
main和release/*→ merge only, no force push；feature/*→ create & push，但禁止删除；hotfix/*→ 仅 release-manager + security-team 可 push - 注意：
git branch -d本地删分支不触发权限检查，但git push origin :feature/xxx删除远程分支会校验权限 —— 很多人误以为“删本地就没事”，其实远程残留分支可能被误用
git merge 都有不可抵赖的动作链：谁发起、谁审查、什么检查通过、是否签名、是否打标。这些信息全在 Git 对象里存着，查 git log --show-signature 就能验证。一旦出事，不是问“谁写的代码”，而是问“哪条策略没被执行”。 
