2. 多团队协作模型：Git分支策略与命名空间隔离
在多团队 GitOps 流水线中，分支策略决定了代码集成频率、冲突概率和回滚复杂度。选择合适的分支模型，并配合团队命名空间隔离，是保障多团队并行交付的基础。
2.1 主流分支策略对比
| 特性 | Trunk-based Development | GitFlow |
|---|---|---|
| 核心分支 | main（主干） | main + develop + feature + release + hotfix |
| 分支生命周期 | 短命特性分支（< 1天） | 长命特性分支（数天～数周） |
| 集成频率 | 每日多次合并到主干 | 特性完成后合并到 develop |
| 冲突风险 | 低（频繁同步） | 高（长时间隔离） |
| 回滚复杂度 | 低（单点回滚） | 中（需处理合并提交链） |
| 适用场景 | 微服务、CI/CD 成熟、DevOps 文化强 | 版本发布严格、多版本维护、传统企业 |
| GitOps 适配度 | 高（声明式状态与主干对齐） | 中（需额外处理 release 分支同步） |
实践建议： 对于 GitOps 流水线，推荐以 Trunk-based 为主干策略。主干分支直接对应 GitOps 的“期望状态”，减少分支到环境的映射复杂度。若团队必须使用 GitFlow，则需为 release 和 hotfix 分支单独配置 ArgoCD Application 或 Flux Kustomization。
2.2 团队命名空间隔离模型
在多团队共享同一 Git 仓库时，必须通过命名空间隔离来避免配置冲突和误操作。推荐以下三层隔离结构：
- 仓库级隔离： 每个团队拥有独立 Git 仓库（
team-a-config、team-b-config）。 - 目录级隔离： 在共享仓库中按团队目录划分（
teams/team-a/、teams/team-b/）。 - 分支级隔离： 每个团队在共享仓库中使用独立分支前缀（
team-a/feature-xxx）。
| 隔离层级 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|
| 仓库级 | 权限独立、无冲突、回滚范围小 | 仓库数量多、跨团队编排复杂 | 团队间耦合低、独立交付 |
| 目录级 | 统一管理、跨团队引用方便 | 需 CodeOwner 保护、目录权限需工具支持 | 共享基础设施、统一 GitOps 入口 |
| 分支级 | 灵活、无需额外仓库 | 分支管理成本高、易冲突 | 小团队、快速原型 |
避坑提醒： 分支级隔离在 GitOps 中风险最高。ArgoCD 默认监听整个仓库，若团队 A 的分支被误删，可能触发团队 B 的环境同步异常。建议至少使用目录级隔离，并配合
.argocd-ignore 或 Flux 的 --ignore-path 过滤。
2.3 分支策略与命名空间结合实践
以下是一个结合 Trunk-based 与目录级隔离的 GitOps 仓库结构示例：
gitops-config/
├── teams/
│ ├── team-a/
│ │ ├── base/ # 基础配置（Deployment、Service）
│ │ ├── overlays/
│ │ │ ├── dev/
│ │ │ ├── staging/
│ │ │ └── prod/
│ │ └── kustomization.yaml
│ └── team-b/
│ ├── base/
│ ├── overlays/
│ └── kustomization.yaml
├── shared/ # 共享配置（Ingress、CertManager）
├── clusters/ # 集群级配置
└── .github/
└── CODEOWNERS # 按目录分配审批人
关键规则：
- 主干分支
main始终代表生产环境的期望状态。 - 每个团队在
teams/下拥有独立目录，目录内使用 Kustomize overlay 区分环境。 - PR 合并到
main前，必须通过 CI 验证和团队 CodeOwner 审批。 - 回滚时，只需 revert 对应目录的提交，不影响其他团队配置。
2.4 多团队协作流程 SVG 图
2.5 分支策略选择决策树
根据团队规模和发布节奏，可按以下决策树选择分支策略：
- 团队数量 > 5 且发布周期 < 1 周？ → Trunk-based + 目录级隔离
- 团队数量 > 5 且发布周期 > 2 周？ → GitFlow + 仓库级隔离
- 团队数量 < 5 且发布周期灵活？ → Trunk-based + 分支级隔离（短期过渡）
- 需要同时维护多个生产版本？ → GitFlow + release 分支 + 仓库级隔离
核心原则： 分支策略服务于回滚效率。在 GitOps 中，回滚的本质是“将期望状态恢复到上一个已知正确的提交”。分支越少、隔离越清晰，回滚操作就越快、越安全。