为什么必须版本化
没有版本控制的自动化资产只能靠人记：谁改的、改了什么、上一次能跑通的版本是哪份，都无从查证。纳入版本控制后，每次改动都有提交记录与差异，回退只需切回上一个可用版本；同时多人改同一份资产时能通过分支与评审避免互相覆盖。对运维而言，版本控制最重要的价值是让「回到已知可用状态」成为一条命令。
基本信息
| 应纳入版本控制 | 脚本、角色、模板、变量文件、清单、流水线定义 |
|---|---|
| 不应入库 | 明文凭据、私钥、临时导出数据 |
| 凭据处理 | 使用独立密钥管理并在运行时注入 |
| 配套流程 | 提交评审、版本标记、变更记录 |
版本控制的直接收益
- 可回溯：任意一次变更能查到提交人、时间与原因。
- 可回退：出现问题时切回上一版本，而不是凭记忆撤销。
- 可评审：改动在合并前被他人看过，降低低级错误上线概率。
- 可并行：多人同时开发互不阻塞，靠分支与合并收敛。
- 可审计：合规检查时能出示完整的变更链条。
常见资产与版本化要求
| 资产类型 | 版本化要求 | 易被忽略的点 |
|---|---|---|
| 脚本与角色 | 必须入库并评审 | 个人目录里的临时改法被当成事实标准 |
| 变量文件 | 必须入库并按环境分层 | 悄悄改生产变量而不留记录 |
| 主机清单 | 静态清单入库，动态清单留脚本 | 清单写死了已下线主机 |
| 模板文件 | 必须入库 | 模板与生成后的文件不一致 |
| 凭据 | 不入库，走密钥管理 | 为图省事把口令写进变量文件 |
凭据一旦进入版本历史就很难彻底清除：即使后续删除，历史提交里仍然存在。发现误提交后应按凭据泄露流程立即轮换，而不是只删掉文件。
版本化要配套标签与发布节奏：生产执行应指向明确的版本或标签，而不是仓库的默认分支，否则任何一次合并都会立刻影响生产。