4、版本控制基础：Git核心概念、分支策略（Git Flow、Trunk-Based）、.gitignore配置
在Terraform配置审计与版本控制方案中，Git是承载所有基础设施即代码（IaC）变更的基石。本章将深入讲解Git的核心概念、两种主流分支策略的适用场景，以及针对Terraform项目的.gitignore配置规范，确保团队协作时配置文件的完整性与安全性。
4.1 Git核心概念与数据模型
理解Git的底层数据模型是正确使用分支策略的前提。Git本质上是一个内容寻址文件系统，核心对象包括：
| 对象类型 | 存储内容 | SHA-1哈希示例 |
|---|---|---|
| Blob | 文件内容（二进制或文本） | e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 |
| Tree | 目录结构及文件列表（指向Blob或子Tree） | a1b2c3d4e5f6... |
| Commit | 快照元数据（父Commit、Tree、作者、时间、消息） | f7a8b9c0d1e2... |
| Tag | 指向特定Commit的引用（含签名信息） | v1.0.0 |
关键认知： Git的
git add操作将工作区文件写入Blob并暂存到索引区；git commit则创建一个新的Commit对象，其Tree对象记录了当前仓库所有文件的完整快照。这意味着每次提交都是项目状态的完整备份，而非增量差异。
下图展示了Git中工作区、暂存区与本地仓库之间的数据流转关系：
4.2 分支策略：Git Flow vs Trunk-Based
分支策略决定了团队如何组织代码变更、进行代码审查以及发布版本。对于Terraform基础设施项目，选择合适的分支策略直接影响变更的审计追溯能力和部署风险控制。
4.2.1 Git Flow 分支模型
Git Flow是一种长期分支策略，适合需要严格版本管理和多环境并行开发的场景。其核心分支包括：
- master/main：生产就绪分支，所有发布版本均从此分支打Tag。
- develop：日常开发集成分支，所有功能分支合并至此。
- feature/*：新功能开发分支，从develop分支创建，完成后合并回develop。
- release/*：预发布分支，从develop分支创建，用于测试和修复，完成后合并到master和develop。
- hotfix/*：紧急修复分支，从master分支创建，修复完成后合并到master和develop。
适用场景： 当Terraform配置需要同时维护多个环境（如开发、预发布、生产）且每个环境有独立的版本号时，Git Flow能提供清晰的发布节奏和回滚路径。但分支数量较多，合并冲突频率较高。
4.2.2 Trunk-Based Development（主干开发）
Trunk-Based Development强调短生命周期分支，所有开发者直接向主干（main/master）提交代码，或通过极短命名的特性分支（通常不超过一天）合并。其核心原则包括：
- 主干始终处于可发布状态。
- 特性分支从主干创建，合并前必须通过CI/CD流水线验证。
- 禁止长期存在的功能分支，避免大规模合并冲突。
- 通过特性开关（Feature Toggle）控制未完成功能的暴露。
推荐理由： 对于Terraform基础设施项目，Trunk-Based策略能显著降低合并冲突风险，确保每个提交都经过自动化审计（如
terraform fmt、terraform validate、tflint），非常适合持续部署（CD）场景。
下表对比了两种分支策略在Terraform项目中的关键差异：
| 对比维度 | Git Flow | Trunk-Based |
|---|---|---|
| 分支数量 | 多（长期存在develop、release、hotfix） | 少（仅主干+短命特性分支） |
| 合并频率 | 低（功能完成时合并） | 高（每日多次合并） |
| 冲突风险 | 高（长期分支导致冲突累积） | 低（频繁同步主干） |
| 审计追溯 | 强（每个发布有明确分支和Tag） | 强（每个提交经过CI验证） |
| 环境管理 | 适合多环境独立版本 | 适合单一环境持续部署 |
| 回滚复杂度 | 低（通过Tag回滚） | 中（通过git revert回滚） |
下图展示了Trunk-Based Development在Terraform项目中的典型工作流：
4.3 .gitignore 配置规范
在Terraform项目中，.gitignore文件用于排除不应提交到版本控制系统的文件，包括敏感信息、临时文件、依赖缓存和本地配置。错误的.gitignore配置可能导致状态文件泄露或构建环境不一致。
4.3.1 必须忽略的文件类型
- 状态文件：
*.tfstate、*.tfstate.*（包含明文敏感信息，必须使用远程后端存储） - 本地配置：
*.tfvars（通常包含AK/SK、密码等凭据） - 依赖缓存：
.terraform/（包含Provider二进制文件和模块缓存） - 临时文件：
*.log、crash.log、override.tf、override.tf.json - IDE/编辑器配置：
.vscode/、.idea/、*.swp、*.swo
4.3.2 标准 .gitignore 模板
# Terraform 状态文件（禁止提交）
*.tfstate
*.tfstate.*
# 本地变量文件（包含敏感信息）
*.tfvars
*.tfvars.json
# Terraform 依赖缓存目录
.terraform/
# 临时覆盖文件
override.tf
override.tf.json
*_override.tf
*_override.tf.json
# CLI 配置文件
.terraformrc
terraform.rc
# 日志文件
*.log
crash.log
crash.*.log
# IDE 配置
.vscode/
.idea/
*.swp
*.swo
*~
# 操作系统隐藏文件
.DS_Store
Thumbs.db
安全警告： 切勿将
*.tfvars或*.tfstate文件提交到Git仓库。如果误提交，应立即使用git filter-branch或BFG Repo-Cleaner工具从历史记录中彻底清除，并轮换所有暴露的凭据。
4.3.3 分支策略与 .gitignore 的协同
无论采用Git Flow还是Trunk-Based策略，.gitignore文件本身必须纳入版本控制，并确保在所有分支中保持一致。建议在项目初始化时即创建该文件，并通过以下方式维护：
- 在
main分支上定义.gitignore基线版本。 - 所有特性分支从
main创建时自动继承该文件。 - 如果需要在特定分支上临时忽略额外文件（如调试日志），使用
.git/info/exclude（本地生效，不提交）。 - 定期使用
git check-ignore -v <file>验证文件是否被正确忽略。
审计要点： 在代码审查（Code Review）环节，应检查
.gitignore是否遗漏了.terraform/或*.tfvars等关键条目。建议在CI流水线中添加git status --porcelain检查，确保没有敏感文件被意外暂存。