Git 中的 OpenVPN 配置文件：提交前该删掉什么

配置文件同时承担两件事：记录连接设置，以及携带一套能用的凭据。文件扩展名完全不能告诉你手里拿的是哪一种。在断定它属于仓库之前，请先读内容。

下面的步骤假设你正在考虑把客户端模板纳入版本控制。请按顺序执行，凡是你不能吊销的东西，都在提交前停下。

先读你准备暂存的文件

从实际字节看起，因为引用独立文件的配置文件和把内容内嵌进去的配置文件看起来完全不同。搜索 PEM 块的标记，以及名为 ca、cert、key、tls-auth 和 tls-crypt 的内联标签，同一遍扫描就能看出两种情形。加密的私钥仍然算敏感材料，而共享的 tls-auth 或 tls-crypt 密钥是凭据，即使它不是某个用户的身份。对与配置文件一起暂存的任何东西都做同样的检查，包括引用凭据文件的归档和安装脚本。

然后看已暂存的集合，而不是工作树。git diff --cached 会显示这次提交真正会包含什么，只有这个版本对这个决定有意义。

决定仓库可以分发什么

模板可以携带共享的、经过评审的设置，以及为每个人在注册时收到的东西准备具名占位符。它不能携带的是可用的身份，因为仓库会分发给所有能读它的人，包括自动化。私有仓库只是缩小了读者范围，并没有改变每一位读者是否有权获得那份凭据这个问题。

忽略规则只阻止未来的添加，对已经记录在案的内容毫无作用。这种不对称值得在第一次提交之前就想清楚，而不是在第十次之后。基础设施的名称和地址是另一回事：它们不是认证机密，但可能泄露超出团队发布意愿的信息。请明确做出那个判断，而不是把每一行都塞进密码或公开两类。

如果材料已经在历史里

在新提交里删掉那一行，任何拉取的人仍然能拿到旧版本。把暴露当作真实发生的：先确定凭据类型，再找到能使其失效的机构。客户端证书会被吊销，吊销列表重新生成；共享的控制通道密钥要在服务器和每个使用它的客户端上更换。

两者的影响范围差别很大，计划应当在一开始就说明你在执行哪一种。用 git log --all -S 'BEGIN PRIVATE KEY' 这样的搜索定位引入该材料的那次提交，让清理范围是已知的而不是猜的。同事的克隆或某个分支副本可能早就持有旧对象，所以吊销在前，清理在后。

先控制住，再清理

重写历史会改变你所编辑的那次提交之后的每一次提交，因此首先需要仓库所有者和在其中工作的人达成一致。强制推送不是修复；它是一次带有自身回滚风险的协调事件。请安排时间、做备份，并提前告诉团队。

之后要验证当前树和剩余历史，而不是相信工具给的摘要。

把结果留成两样东西：可以安全分享的模板，以及通过注册流程签发的凭据清单。两者都不需要把可用的身份留在仓库里。

这个拆分才是真正的修复，而且它能扛过下一个想提交配置文件的人。