在 2017 年维基解密发布的 Vault 7 事件中，除了大量 CIA 黑客工具外，还泄露了一批内部开发文档。其中一页关于 Git 技巧的文档意外地在开发者社区广为流传 —— 一个用于清理已合并分支的单行命令，至今仍被许多工程师放在自己的 Shell 配置中。这个看似简单的命令不仅提升了日常开发效率，更在 CI/CD 管道安全实践中具有重要防护意义。
Vault 7 泄露的 Git 单行命令
Vault 7 泄露的 CIA 内部开发文档中记载了这个分支清理命令：
git branch --merged | grep -v "\*\|master" | xargs -n 1 git branch -d
该命令的工作原理并不复杂：首先通过 git branch --merged 列出所有已合并到当前分支的本地分支，随后使用 grep -v 过滤掉当前分支和主分支（防止误删），最后通过 xargs -n 1 逐个执行 git branch -d 进行安全删除。值得注意的是这里使用的是小写 -d 参数而非大写的 -D，这意味着该命令只会删除已完全合并的分支，对于存在未合并提交的分支会直接跳过，从而避免了数据丢失风险。
现代项目普遍将默认分支从 master 改为 main，因此更新后的版本更加通用：
git branch --merged origin/main | grep -vE "^\s*(\*|main|develop)" | xargs -n 1 git branch -d
这条命令将比较基准改为 origin/main，同时排除了 main 和 develop 两个常用分支，可以直接作为别名写入 Shell 配置文件中长期使用。
CI/CD 管道中的安全价值
在持续集成和持续部署环境中，分支清理具有远超「保持仓库整洁」的安全意义。当一个项目长期运行后，遗留的废弃分支可能包含过时的凭证信息、敏感的环境变量配置，或者是已经修复但未删除的安全漏洞测试代码。这些「陈旧分支」往往被开发者遗忘，却可能成为攻击者的突破口。通过在 CI/CD 管道中集成上述清理命令，可以在每次部署时自动移除已合并的分支，从而缩小代码库的受攻击面。
从合规角度看，许多安全审计标准要求对代码仓库进行定期清理。已合并但未删除的分支在技术上仍然可以被克隆和审查，即使它们已经不会影响生产代码。将分支清理集成到部署流程中，可以确保仓库始终保持最小必要原则，减少敏感信息意外暴露的可能性。此外，干净的分支列表也有助于安全工具更快地完成代码扫描，避免因分支数量过多导致的扫描超时或遗漏。
可落地的工程参数与监控要点
在实际工程实践中，建议将分支清理命令作为 Git Hook 或 CI/CD Pipeline 的一个独立步骤。可以在部署完成后的清理阶段执行该命令，并设置日志记录以便审计。如果项目使用 GitHub Actions，可以在工作流的最后阶段添加一个「cleanup」Job，专门负责分支清理和临时文件删除。需要排除的分支列表应当通过环境变量或配置文件管理，避免硬编码。
针对不同角色的工程师，可以设置差异化的清理策略：开发分支可以设置较短的存活周期（如 7 天），而发布分支则需要保留更长时间以支持热修复。配合 Git 的 branch.autosetuprebase 配置，还可以进一步优化分支的合并历史，减少冲突发生的概率。在监控层面，建议将「活跃分支数量」纳入代码仓库的健康度指标，当分支数量异常增长时触发告警。
Vault 7 泄露的这份文档虽然出自 CIA 内部，但其展现的工程实践思路值得借鉴。将安全意识融入日常的开发工具链中，往往比专门的安全防护措施更加有效。掌握并正确使用这些看似简单的命令，就是对自己项目安全的一种务实提升。
资料来源：Spencer Dixon Blog（spencer.wtf）