第 3 章 管控风险

不可逆操作与合规红线由维护者最终把关。

3.1 保密与数据合规

• 未公开数据集不得随 PR 发布至公开平台；内部可共享，未经许可不得外传。
• 第三方数据集须确认使用许可允许内部存储与运行。
• Issue、PR 中的数据、日志、截图受保密制度约束；数据须注明来源，不得直接传输原始数据。

3.2 敏感内容拦截

PR 中发现以下内容立即拦截并上报，不予合并：

• 硬编码的密码、密钥、令牌。
• 内部服务器地址或 IP。
• 不应纳入版本控制的数据文件（大规模原始数据、私人信息）。
• 外部仓库地址（GitHub 等外部平台 URL）。

开发者误提交敏感文件时，禁止自行 --force 覆盖历史，应通知维护者，由维护者联系管理员清理。

3.3 实验分支不合并

分支命名、不合并与实验记录要求见《用户层手册》第 3.5 节。

• 维护者应在 PR 审批中驳回 experiment/* 未经重构与测试即合入 main 的提交。
• 经确认的有效成果，由维护者协助新建 feature/* 分支手动移植，再走 PR 评审合入。
• 不再活跃的实验分支按第 4 章打 archive/exp-* tag 后删除。

3.4 特权操作授权

• git push --force、历史重写、仓库历史清理等破坏性操作，仅由管理员在明确授权下执行。
• 维护者遇此类需求转交管理员并留存记录。

3.5 敏感信息泄露后的历史清理（管理员操作）

当密钥、密码、令牌或内部地址已被 push 到远程，仅删文件不够——历史里仍可检出。须由管理员执行历史清理。核心认知：一旦推送即视同泄露，清理历史不等于没泄露过。

第一步：先止血，再清理。

• 立即通知全体成员停止 push / pull，等待清理完成。
• 泄露的密钥 / 密码 / 令牌一律作废并更换（吊销旧密钥、重置密码、重签令牌）。这一步优先级高于清历史。

第二步：用 git filter-repo 清理历史。 推荐 git filter-repo（官方推荐，已取代废弃的 filter-branch）：

# 安装（任选其一）
pip install git-filter-repo

# 在仓库的一份全新克隆中操作（filter-repo 要求干净克隆）
git clone <仓库地址> repo-clean
cd repo-clean

# 方式一：彻底删除某个误提交的敏感文件（连同全部历史）
git filter-repo --path config/secret.key --invert-paths

# 方式二：替换所有历史中的敏感字符串（把明文替换为占位符）
# 先建一个替换规则文件 replacements.txt，每行形如：
#   old-secret-value==>REMOVED
git filter-repo --replace-text replacements.txt

第三步：强制推送并要求全员重建。

git push origin --force --all
git push origin --force --tags

• 清理会改写所有提交哈希，其他成员必须重新 clone（不能 pull），否则旧历史会被重新推回。
• 通知全员：删除本地旧仓库 → 重新 clone 干净版本 → 重配本地分支。

3.6 风险红线清单

红线	处理动作
密钥 / 密码 / 令牌	拦截 + 上报 + 清理历史
内部地址 / IP	拦截
外部仓库地址	拦截，转为内部地址
实验分支直接合入 main	驳回，要求走 feature 移植
强制推送 / 历史重写	仅由管理员授权执行

对应《用户层手册》第 5 章（保密）与第 3 章（experiment 不合并）。

---