2. 数据平台代码仓库分支策略设计与落地
为什么数据平台需要统一分支模型
数据平台的代码资产类型差异很大：SQL 脚本、Python ETL、调度 DAG 配置、Schema/DDL 定义、元数据映射文件。它们的变更频率、影响范围和回滚代价各不相同，但共享同一套发布节奏。如果每种资产各自约定分支命名，合并时就会出现“SQL 已上线、调度配置还没合”的错位。统一分支模型的目标是：让所有资产在同一时间点拥有可追溯的版本快照，并让并行开发互不阻塞。
主干 / 发布 / 热修三层分支模型
推荐采用三层长期分支加两类短期分支的结构：
- main（主干）：始终对应“已通过 CI 但未发布”的集成状态，所有 feature 分支合并到此。
- release/*（发布分支）：从 main 切出，冻结后只接受缺陷修复，用于对应一次生产发布窗口。
- hotfix/*（热修分支）：从 release 或 main 切出，修复线上问题，修复后同时回合 main 与 release。
- feature/*（特性分支）：从 main 切出，承载单个需求或缺陷，生命周期短。
- schema/*（Schema 变更分支）：Schema 变更影响面大，单独走一条带额外审批的分支路径。
分支保护规则配置
分支模型只有配合保护规则才能落地。以下规则以 Git 平台通用能力为准，具体菜单名称可能因平台而异，但配置逻辑一致。
| 分支 | 允许直接推送 | 合并前要求 | 审批人数 | 特殊规则 |
|---|---|---|---|---|
| main | 否 | CI 通过 + 至少 1 人审批 | 1 | 禁止 force push，禁止删除 |
| release/* | 否 | CI 通过 + 至少 2 人审批 | 2 | 仅允许 hotfix 和缺陷修复合并 |
| hotfix/* | 是（仅限指定人员） | CI 通过 | 1 | 合并后自动触发回合 main 和 release |
| feature/* | 是 | 无 | 0 | 合并到 main 时触发完整 CI |
| schema/* | 否 | CI 通过 + DBA 审批 | 2 | 必须附带回滚 DDL，禁止 DROP/TRUNCATE |
多类型资产的合并冲突预防
SQL、Python、调度配置、Schema 定义在同一仓库中并行开发时，冲突主要来自三类场景：
- 同一 DAG 文件被多人修改：调度配置通常按 DAG 粒度组织，建议每个 DAG 文件只由对应负责人修改，feature 分支合并前先 rebase main。
- Schema 变更与 SQL 变更交叉：Schema 分支合并后，依赖该表的 SQL 分支必须 rebase 最新 main，否则 CI 中的方言校验会因字段缺失而失败。
- Python 依赖版本冲突：requirements 或 pyproject 文件变更走独立 PR，合并前由 CI 执行依赖解析检查。
落地建议：先用
CODEOWNERS 文件按目录指定负责人，例如 /dags/ @调度组、/schema/ @DBA、/etl/ @数据工程组。这样分支保护规则中的“审批人数”可以自动路由到正确的人，而不是随机等待。
验证分支模型是否生效
配置完成后，用以下检查项确认模型真正落地：
- 尝试直接向 main 推送一个提交，应被拒绝。
- 创建一个 feature 分支，修改一个 SQL 文件，发起合并请求，确认 CI 被触发且审批人被自动指定。
- 创建一个 schema 分支，修改 DDL，确认 DBA 审批被要求且回滚 DDL 检查生效。
- 模拟 hotfix 合并后，确认 main 和 release 分支都收到了回合提交。
常见误区：只建分支不配保护规则，等于没有分支模型。另一个误区是把 release 分支当成长期开发分支使用，导致发布窗口无法冻结。release 分支一旦切出，只接受缺陷修复，新功能必须回到 main 等待下一个发布窗口。