4. Git仓库结构设计：仓库目录规划、分支策略与版本管理

事故响应台账的GitOps配置同步机制，其底层依赖一个严谨、可审计的Git仓库结构。仓库结构设计直接决定了变更追溯的清晰度、多环境部署的可靠性以及紧急修复的效率。本节从目录规划、分支策略、标签与版本管理三个维度展开。

4.1 仓库目录规划

采用单仓库多环境模式，将事故响应台账的配置、部署清单、自动化策略统一存放在一个Git仓库中。目录结构按功能域分层，避免配置散落。

4.2 分支策略

采用主干开发 + 环境分支 + 热修复分支的三层分支模型，兼顾持续交付速度与事故场景下的紧急响应能力。

4.2.1 分支类型与职责

4.2.2 分支工作流示例

1. 日常变更：从 main 创建 feature/ 分支 → 修改配置 → 提交 MR → 代码审查 → 合并到 main → GitOps 自动同步到预发环境验证 → 手动触发生产同步。
2. 紧急热修复：从 main 创建 hotfix/ 分支 → 修复配置 → 跳过完整审查（需事故经理审批）→ 合并到 main → 自动同步到生产环境 → 事后补全审查记录。
3. 版本发布：从 main 创建 release/ 分支 → 冻结配置变更 → 集成测试 → 打标签 → 合并回 main。

4.3 标签与版本管理

标签是GitOps同步的锚点，GitOps Operator 通过监听特定标签模式来触发环境同步。版本管理遵循 语义化版本 2.0.0，并附加事故响应元数据。

4.3.1 标签命名规范

4.3.2 版本号递增规则

• 主版本（MAJOR）：事故台账配置模型发生不兼容变更，如事故分类体系重构。
• 次版本（MINOR）：新增事故类型、SLA 模板、通知渠道等向下兼容的功能。
• 补丁（PATCH）：修复配置错误、同步逻辑缺陷、文档修正。
• 热修复补丁：在补丁版本基础上立即递增，并附加 -hotfix.<incident-id> 后缀。

4.3.3 标签创建自动化示例

# 在 CI/CD 流水线中自动创建标签（GitHub Actions 片段）
- name: Create and push Git tag
  run: |
    VERSION="v$(cat VERSION)"
    if [[ "${{ github.event_name }}" == "push" && "${{ github.ref }}" == "refs/heads/main" ]]; then
      git tag "env/prod/${VERSION}"
      git push origin "env/prod/${VERSION}"
    fi

4.4 仓库结构设计检查清单

仓库结构设计是事故响应台账 GitOps 配置同步的基石。目录规划决定了配置的可维护性，分支策略保障了日常变更与紧急修复的并行效率，标签与版本管理则为 GitOps 同步提供了精确的锚点。三者协同，才能实现“配置即代码、变更可追溯、同步可自动化”的 SRE 目标。