4. Git 作为单一事实来源：Git 仓库结构设计
在 GitOps 控制平面中，Git 仓库不仅是代码托管工具，更是整个系统的单一事实来源（Single Source of Truth）。所有环境状态、配置参数、应用版本都必须以 Git 仓库中的声明式描述为准。仓库结构设计的合理性直接决定了 GitOps 工作流的可维护性、安全性和扩展性。
4.1 仓库结构设计模式
根据组织规模和运维复杂度，GitOps 仓库结构通常分为三种模式：单仓库（Monorepo）、多仓库（Multi-Repo）和分层仓库（Layered Repo）。下表对比了三种模式的核心差异：
| 维度 | 单仓库（Monorepo） | 多仓库（Multi-Repo） | 分层仓库（Layered Repo） |
|---|---|---|---|
| 定义 | 所有应用代码、环境配置、基础设施定义放在一个 Git 仓库中 | 每个应用、每个环境各自独立仓库 | 按职责分层：应用仓库、环境仓库、配置仓库 |
| 优势 | 原子性提交、跨组件重构简单、权限统一 | 独立发布、细粒度权限、仓库体积小 | 职责分离、环境隔离、配置复用 |
| 劣势 | 仓库体积大、权限粒度粗、CI 触发频繁 | 跨仓库协调困难、版本一致性难保证 | 管理复杂度中等、需要工具链支持 |
| 适用场景 | 初创团队、微服务数量 < 10、统一发布 | 大型组织、独立团队、严格安全合规 | 中型团队、多环境、多租户 |
推荐实践：对于大多数企业级 GitOps 落地场景，分层仓库是最佳平衡点。它将应用代码、环境定义、配置参数解耦，既保留了多仓库的隔离性，又通过工具链（如 Kustomize、Helm）实现跨仓库的版本关联。
4.2 分层仓库结构详解
分层仓库将 GitOps 资源按职责拆分为三个独立仓库，每个仓库承担不同的角色：
- 应用仓库（Application Repo）：存放应用源代码、Dockerfile、CI 流水线定义。开发人员在此提交代码，CI 构建出容器镜像并推送至镜像仓库。
- 环境仓库（Environment Repo）：存放每个环境（dev/staging/prod）的 Kubernetes 资源清单。包含 Deployment、Service、Ingress 等 YAML 文件，以及 Kustomize overlay 或 Helm values。
- 配置仓库（Config Repo）：存放全局共享配置，如集群级别的 ConfigMap、Secret 模板、策略规则（OPA/Gatekeeper）、基础设施定义（Terraform/Crossplane）。
关键原则：环境仓库是 GitOps 控制平面的核心。ArgoCD 或 Flux 只监听环境仓库的变更，应用仓库和配置仓库通过 CI/CD 流水线将产物（镜像 tag、配置版本）写入环境仓库，从而触发同步。
4.3 分支策略：GitFlow vs Trunk-Based
分支策略决定了团队如何协作、如何触发 GitOps 同步。在 GitOps 语境下，分支策略不仅影响代码合并，还直接影响环境部署的节奏和安全性。
| 维度 | GitFlow | Trunk-Based Development |
|---|---|---|
| 核心分支 | main（长期）、develop（长期）、feature、release、hotfix | main（或 trunk）、短生命周期 feature 分支 |
| 分支生命周期 | feature 分支持续数天到数周 | feature 分支持续数小时到 1-2 天 |
| 合并频率 | 低（每天 1-2 次合并到 develop） | 高（每天多次合并到 main） |
| GitOps 同步触发 | 合并到 main 或 release 分支时触发 | 合并到 main 分支时立即触发 |
| 环境映射 | develop → dev，release → staging，main → prod | main → dev/staging/prod（通过 tag 或 commit 标识） |
| 优势 | 发布节奏可控、hotfix 隔离 | 低延迟、减少合并冲突、CI 反馈快 |
| 劣势 | 合并复杂、长期分支导致 drift | 需要高质量自动化测试、不适合严格发布窗口 |
GitOps 适配建议：GitFlow 的长期 develop 分支容易与环境仓库中的 dev 环境产生状态漂移（drift），因为 develop 分支的变更不会立即同步到集群。推荐在 GitOps 场景下优先采用 Trunk-Based Development，配合环境标签（如 v1.2.3-dev、v1.2.3-prod）实现环境隔离。
4.4 环境仓库分支策略最佳实践
环境仓库是 GitOps 控制平面的核心，其分支策略应遵循以下原则：
- 环境即分支（Environment as Branch）：每个环境对应一个长期分支，如
dev、staging、prod。GitOps 控制器监听对应分支的变更。 - 禁止直接推送到 prod 分支：所有对 prod 分支的变更必须通过 Pull Request，并经过代码审查和自动化策略检查（如 OPA 策略）。
- 使用语义化版本标签：合并到 prod 分支时，自动打上语义化版本标签（如
v1.2.3），用于回滚和审计。 - 环境提升（Environment Promotion）：代码从 dev → staging → prod 的提升过程，通过合并分支或复制 commit 实现，确保每个环境的状态在 Git 中都有完整记录。
4.5 配置仓库的版本管理
配置仓库中的全局配置（如集群级别的 ConfigMap、Secret 模板、策略规则）通常被多个环境共享。推荐使用以下版本管理策略：
- 语义化版本标签：每次配置变更合并到 main 分支后，自动打上
v1.0.0格式的标签。环境仓库通过引用配置标签（如configVersion: v1.0.0）来锁定配置版本。 - 配置继承与覆盖：使用 Kustomize 的
patches或 Helm 的values实现环境级配置覆盖。配置仓库只存放全局默认值，环境仓库中的 overlay 目录存放环境特定值。 - 配置审计：所有配置变更必须通过 PR，并记录变更原因。Git 历史天然提供配置变更的审计轨迹。
配置仓库目录结构示例：
config-repo/
├── base/ # 全局基础配置
│ ├── kustomization.yaml
│ ├── cluster-config.yaml
│ └── policy/
│ └── require-labels.yaml
├── overlays/
│ ├── dev/ # dev 环境覆盖
│ │ ├── kustomization.yaml
│ │ └── replica-count.yaml
│ ├── staging/
│ │ ├── kustomization.yaml
│ │ └── resource-limits.yaml
│ └── prod/
│ ├── kustomization.yaml
│ └── tls-certificate.yaml
└── versions/ # 版本标签记录
└── v1.0.0.yaml4.6 仓库结构设计检查清单
在落地 GitOps 仓库结构时，建议对照以下清单进行验证：
| 检查项 | 描述 | 通过标准 |
|---|---|---|
| 单一事实来源 | 所有环境状态是否都能从 Git 仓库中完整恢复 | 从零开始 clone 仓库并执行 sync 后，集群状态与预期一致 |
| 环境隔离 | 不同环境的配置是否完全隔离 | dev 分支的变更不会影响 prod 集群 |
| 权限最小化 | 是否按仓库和分支设置了细粒度权限 | 开发人员只能写 dev 分支，运维人员可写 staging/prod 分支 |
| 版本可追溯 | 每次部署是否都能追溯到具体的 Git commit | ArgoCD/Flux 界面显示 commit SHA 和标签 |
| 配置复用 | 全局配置是否被多个环境共享且可覆盖 | 修改 base 配置后，所有环境通过 PR 选择是否继承 |
通过合理的仓库结构设计和分支策略，GitOps 控制平面能够实现可审计、可回滚、可复现的部署流程，真正发挥 Git 作为单一事实来源的核心价值。