4. Git 仓库策略：Monorepo vs 多仓库、环境分支策略与目录结构设计
在 GitOps 流水线中，仓库策略是基础设施即代码（IaC）和应用程序配置管理的基石。选择错误的策略会导致协作混乱、部署冲突和审计困难。本章将深入剖析三种核心决策：Monorepo vs 多仓库、环境分支策略以及目录结构设计，帮助你在开发到生产的全链路中建立清晰、可追溯的配置管理模型。
核心原则： GitOps 要求仓库是单一事实来源（Single Source of Truth）。无论选择哪种策略，都必须确保仓库状态与集群实际状态一致，且所有变更通过 Pull Request 驱动。
4.1 Monorepo vs 多仓库：架构权衡
选择单一仓库（Monorepo）还是多仓库（Multi-Repo）是 GitOps 实践中的首要决策。下表从多个维度对比两种策略的差异：
| 维度 | Monorepo（单仓库） | Multi-Repo（多仓库） |
|---|---|---|
| 管理复杂度 | 低：单一权限、单一 CI/CD 配置、统一版本控制 | 高：多个仓库权限、多套 CI/CD 流水线、跨仓库协调 |
| 原子性变更 | 支持：一次 PR 可同时修改应用代码、配置和基础设施 | 不支持：跨仓库变更需要多个 PR 和手动协调 |
| 可见性与审计 | 高：所有变更集中在一个仓库，便于全局审计 | 低：变更分散，需要跨仓库追踪关联 |
| 规模扩展 | 受限：仓库体积增长快，clone 和 CI 时间增加 | 良好：每个仓库独立扩展，适合大型团队 |
| 权限粒度 | 粗粒度：通常基于目录路径控制（如 CODEOWNERS） | 细粒度：每个仓库独立设置权限，隔离性更好 |
| 推荐场景 | 中小团队、微服务数量少（<20）、强依赖统一发布 | 大型组织、多团队独立交付、安全隔离要求高 |
实践建议： 对于大多数 GitOps 初学者，建议从 Monorepo 开始。它降低了初始管理成本，并强制团队遵循统一的配置规范。当仓库体积超过 1GB 或 CI 时间超过 15 分钟时，再考虑拆分为多仓库。
下图展示了 Monorepo 与 Multi-Repo 在 GitOps 流水线中的核心差异：
4.2 环境分支策略：GitFlow vs Trunk-Based
分支策略决定了代码如何从开发环境流向生产环境。在 GitOps 中，分支通常直接映射到环境（如 dev、staging、prod）。以下是两种主流策略的对比：
| 特性 | GitFlow | Trunk-Based Development |
|---|---|---|
| 长期分支 | main、develop、release、hotfix | main（或 trunk） |
| 环境映射 | develop → dev，release → staging，main → prod | main → prod，短生命周期 feature 分支 → dev/staging |
| 合并频率 | 低（按发布周期合并） | 高（每日多次合并到 trunk） |
| 回滚复杂度 | 高（需要 revert 或 hotfix 分支） | 低（直接 revert trunk 上的 commit） |
| GitOps 适配性 | 中等：分支多，容易导致配置漂移 | 优秀：单一事实来源，与 GitOps 理念高度契合 |
| 推荐场景 | 传统发布周期、需要严格审批的合规环境 | 持续部署、高频发布、DevOps 成熟团队 |
避坑指南： 在 GitOps 中，避免为每个环境创建长期独立分支（如 dev、staging、prod 各一个分支）。这会导致配置漂移：开发环境修复的 bug 可能永远不会同步到生产环境。推荐使用 Trunk-Based + 环境目录 的组合策略。
下图展示了 Trunk-Based 策略如何通过目录结构而非分支来管理环境差异：
4.3 目录结构设计：可扩展的配置布局
无论选择 Monorepo 还是多仓库，目录结构都直接影响流水线的可维护性。以下是一个经过生产验证的 Monorepo 目录结构模板：
gitops-config/
├── apps/ # 应用配置
│ ├── frontend/
│ │ ├── base/ # 基础配置（环境无关）
│ │ │ ├── deployment.yaml
│ │ │ ├── service.yaml
│ │ │ └── kustomization.yaml
│ │ └── overlays/ # 环境覆盖
│ │ ├── dev/
│ │ │ ├── replica-count.yaml
│ │ │ └── kustomization.yaml
│ │ ├── staging/
│ │ └── prod/
│ └── backend/
├── infra/ # 基础设施配置
│ ├── networking/
│ ├── monitoring/
│ └── storage/
├── clusters/ # 集群定义
│ ├── dev-cluster/
│ │ └── flux-system/
│ └── prod-cluster/
├── envs/ # 环境全局配置
│ ├── dev/
│ │ ├── configmap.yaml
│ │ └── secrets.yaml
│ ├── staging/
│ └── prod/
├── pipelines/ # CI/CD 流水线定义
│ ├── .github/
│ │ └── workflows/
│ └── .gitlab-ci.yml
├── docs/ # 文档
├── .github/ # GitHub 配置
│ ├── CODEOWNERS # 代码所有者
│ └── PULL_REQUEST_TEMPLATE.md
└── README.md
设计要点：
- base/overlays 模式： 使用 Kustomize 的 base/overlays 结构，base 存放环境无关配置，overlays 存放环境差异。这避免了复制粘贴导致的配置漂移。
- 集群与环境分离：
clusters/目录定义集群本身（如 Flux 安装、集群角色），envs/目录定义环境级别的全局配置（如 ConfigMap、Secrets）。 - 应用与基础设施分离：
apps/存放业务应用，infra/存放共享基础设施。这有助于权限隔离和变更影响范围控制。
4.4 策略选择决策树
以下决策树可以帮助你根据团队规模和发布频率快速选择策略：
4.5 关键实践总结
- 仓库策略： 中小团队优先选择 Monorepo，大型组织选择 Multi-Repo。避免混合模式（如 Monorepo 中嵌套多个 Git 子模块），这会破坏原子性。
- 分支策略： 推荐 Trunk-Based Development，通过目录结构（如
envs/dev/、envs/prod/）而非分支来管理环境差异。这减少了分支数量，降低了合并冲突和配置漂移的风险。 - 目录结构： 采用 base/overlays 模式（Kustomize）或 values 文件分层（Helm）。确保环境差异显式声明，而非通过复制粘贴产生隐式差异。
- 自动化验证： 在 CI 流水线中增加
kustomize build或helm template步骤，验证目录结构正确性和 YAML 语法合法性。