3. Git 作为单一可信源：仓库结构、分支策略与提交规范
在 GitOps 模型中，Git 仓库不仅是代码的存储地，更是整个系统状态的单一可信源（Single Source of Truth）。所有环境配置、基础设施定义、策略规则都必须以声明式清单的形式存储在 Git 中，任何对集群的变更都必须通过修改 Git 仓库中的文件来触发。本章将深入讲解如何设计仓库结构、选择分支策略、制定提交规范并实施签名验证，确保 Git 作为可信源的安全性与可审计性。
3.1 仓库结构设计原则
合理的仓库结构是 GitOps 实践的基石。根据团队规模和项目复杂度，通常采用以下两种模式：
| 模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 单仓库（Monorepo） | 中小团队、微服务数量较少（< 10） | 统一管理、原子性变更、简化权限 | 仓库体积大、CI 触发频繁 |
| 多仓库（Multi-Repo） | 大型团队、微服务数量较多（≥ 10） | 独立权限、独立 CI/CD、解耦 | 跨仓库变更协调复杂、审计分散 |
推荐实践：对于大多数企业级 GitOps 项目，建议采用应用仓库 + 配置仓库分离的模式。应用仓库存放业务代码和 Dockerfile，配置仓库（Config Repo）存放 Kubernetes 清单、Helm Chart 和 Kustomize 覆盖层。配置仓库作为真正的单一可信源，严格限制写入权限。
一个典型的配置仓库目录结构示例如下：
config-repo/
├── clusters/ # 集群级别配置
│ ├── production/
│ │ ├── namespaces.yaml
│ │ ├── network-policies.yaml
│ │ └── resource-quotas.yaml
│ └── staging/
│ ├── namespaces.yaml
│ └── network-policies.yaml
├── apps/ # 应用级别配置
│ ├── frontend/
│ │ ├── base/ # 基础配置（环境无关）
│ │ │ ├── deployment.yaml
│ │ │ └── service.yaml
│ │ ├── overlays/ # 环境覆盖
│ │ │ ├── production/
│ │ │ │ └── kustomization.yaml
│ │ │ └── staging/
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── backend/
│ ├── base/
│ ├── overlays/
│ └── kustomization.yaml
├── charts/ # Helm Chart 目录
│ ├── common/
│ └── custom-app/
├── policies/ # 策略即代码（OPA/Gatekeeper）
│ ├── require-labels.rego
│ └── block-privileged.rego
└── README.md
3.2 分支策略：GitFlow 与 Trunk-Based
分支策略决定了变更如何流入 Git 仓库，进而影响 GitOps 的发布节奏和安全管控。以下是两种主流策略的对比：
| 维度 | GitFlow | Trunk-Based Development |
|---|---|---|
| 分支数量 | 多（main, develop, feature, release, hotfix） | 少（main + 短期特性分支） |
| 发布频率 | 低（按版本发布） | 高（持续发布，每日多次） |
| 合并复杂度 | 高（多次反向合并） | 低（线性历史） |
| GitOps 适配度 | 中等（需额外处理 release 分支同步） | 高（main 分支直接对应环境状态） |
| 安全审计难度 | 高（分支多，审计路径分散） | 低（单一主线，审计清晰） |
GitOps 推荐：优先采用 Trunk-Based Development。GitOps 的核心是“main 分支即生产状态”，Trunk-Based 的线性历史和短生命周期分支天然匹配这一理念。如果必须使用 GitFlow，建议将 release 分支的合并操作自动化，并通过 CI 流水线确保 release 分支与 main 分支的配置一致性。
3.3 提交规范与签名验证
提交信息是 Git 历史的“文档”，规范的提交信息可以提升可读性和自动化能力。同时，签名验证确保提交者的身份可信，防止恶意篡改。
3.3.1 提交信息规范（Conventional Commits）
推荐采用 Conventional Commits 规范，格式如下：
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
常用类型说明：
| 类型 | 含义 | 示例 |
|---|---|---|
feat |
新功能 | feat(backend): add health check endpoint |
fix |
Bug 修复 | fix(frontend): correct CSS layout on mobile |
chore |
构建/工具变更 | chore(deps): upgrade ArgoCD to v2.8 |
docs |
文档更新 | docs: update README with deployment steps |
refactor |
重构 | refactor(config): simplify kustomize overlays |
security |
安全修复 | security: fix CVE-2024-XXXX in ingress controller |
自动化提示：可以在 CI 流水线中集成
commitlint 工具，对 PR 中的所有提交信息进行校验，不符合规范的 PR 将被自动拒绝。同时，结合 semantic-release 工具，可以根据提交信息自动生成版本号和变更日志。
3.3.2 GPG 签名验证
GPG（GNU Privacy Guard）签名可以验证提交者的身份，确保提交未被篡改。在 GitOps 场景中，签名验证是防止恶意提交进入单一可信源的关键防线。
配置步骤：
- 生成 GPG 密钥对：
gpg --full-generate-key - 将公钥添加到 Git 平台（GitHub/GitLab/Bitbucket）
- 配置 Git 使用 GPG 签名：
git config --global user.signingkey <KEY_ID> - 启用自动签名：
git config --global commit.gpgsign true - 验证签名：
git log --show-signature
安全警告：仅启用签名还不够，必须在 Git 平台（如 GitHub）的仓库设置中开启 "Require signed commits" 分支保护规则。否则，未签名的提交仍然可以合并到受保护分支，签名验证形同虚设。
3.4 分支保护规则与 RBAC 集成
Git 仓库的分支保护规则是 GitOps 安全权限的第一道防线。结合 RBAC，可以实现精细化的访问控制。
关键保护规则配置：
- 要求 Pull Request 审查：至少 1 名代码所有者批准
- 要求状态检查通过：CI 流水线、lint 检查、安全扫描必须通过
- 要求签名提交：所有提交必须经过 GPG 签名验证
- 限制推送权限：仅允许特定角色（如 Maintainer）直接推送到 main 分支
- 线性历史：禁止合并提交，强制使用 rebase 或 squash 合并
RBAC 集成示例：在 GitHub 中，可以创建团队（Team）并分配角色：
- Developers：只能创建特性分支，通过 PR 提交变更
- Maintainers：可以审查 PR 并合并到 main 分支
- Admins：可以修改分支保护规则和仓库设置
在 GitLab 中，类似的角色体系为 Reporter、Developer、Maintainer、Owner。
- Developers：只能创建特性分支，通过 PR 提交变更
- Maintainers：可以审查 PR 并合并到 main 分支
- Admins：可以修改分支保护规则和仓库设置
在 GitLab 中，类似的角色体系为 Reporter、Developer、Maintainer、Owner。
3.5 审计与合规性
Git 作为单一可信源，其历史记录本身就是最完整的审计日志。结合签名验证和分支保护，可以实现以下合规目标：
| 合规要求 | Git 实现方式 |
|---|---|
| 谁在什么时间做了什么变更 | git log --format="%H %an %ai %s" |
| 变更是否经过审查 | PR/MR 审查记录 + 合并提交信息 |
| 提交者身份是否可信 | GPG 签名验证 + 公钥管理 |
| 变更是否经过 CI 验证 | 状态检查记录（CI 流水线结果） |
| 是否可以追溯历史配置 | git checkout <commit-hash> 恢复任意历史状态 |
审计工具推荐：可以使用
gitinspector 或 gitstats 生成可视化的提交统计报告。对于合规性要求较高的企业，建议将 Git 日志导出到 SIEM（安全信息和事件管理）系统，实现集中审计。
通过以上仓库结构设计、分支策略选择、提交规范制定和签名验证实施，Git 仓库真正成为 GitOps 模型中不可篡改、可审计、可追溯的单一可信源。下一层级的 RBAC 权限控制将在此基础上，进一步细化到文件级别和操作级别。