分支合并策略专家

策略概述

• 推荐策略类型及适用性分析

  • 主干+长期发布分支模型（SVN）：以单一稳定主干（trunk）为基线，在每次计划性发布时从主干切出 release/x.y 分支进行冻结与加固；生产环境运行对应 release 分支的打标版本（tags/vx.y.z）。对仍在维护期内的版本保留长期维护分支（maintenance/x.y），仅接受安全与高优先级修复。
  • 适用性：对于单体、强耦合、自动化薄弱且回滚成本高的 ERP 系统，该模型最小化并行分支数量、降低合并复杂度，同时允许在发布分支上进行充分的稳定化与夜间批处理验证，符合“长期发布”的节奏。
  • 热修策略：从当前生产版本对应的 tag 或 release 分支切热修分支（hotfix/vx.y.z-），修复验证后回灌至主干与所有仍受支持的维护分支，打新 tag 发布。
  • 迁移方向：在保持上述模型不变的前提下，分阶段从 SVN 平滑过渡到 Git，最终在 Git 中沿用 main + release/x.y + maintenance/x.y + tags 的结构与保护策略。

• 核心原则和设计理念

  • 少分支、短存活、强门禁：避免长期功能分支；以主干集成为中心，发布分支仅用于稳定化与热修。
  • 冻结有节奏、发布有节拍：设置软/硬冻结窗口与变更准入规则，降低回归风险。
  • 修复单源、正向合并：生产问题在最接近生产的分支修复（release/maintenance），然后正向合并回主干，防止修复丢失。
  • 可追溯：严格的命名规范、打 tag、变更单与提交信息模板，结合 CI 报告与制品库保证可追踪与可回溯。
  • 渐进增强质量：从编译/静态扫描/关键回归开始，逐步扩充 CI 覆盖面，优先保障夜间批处理路径。

实施步骤

1. 分支创建规范

   • SVN 目录结构
     • /trunk：唯一主干，日常集成与新特性开发。
     • /branches/release/x.y：每次计划发布时从 trunk 切出，进入冻结与稳定化。
     • /branches/maintenance/x.y：对仍在支持期内的历史大版本，保留维护分支；仅接受 P0/P1 修复。
     • /branches/hotfix/vx.y.z-：从 tags/vx.y.z 或对应 release/x.y 切出，用于生产紧急修复。
     • /tags/vx.y.z：只读发布标签，对应制品与部署版本。
   • 命名与元信息
     • 版本号：主版本.x.y.z（主=架构/DB兼容变更，次=功能集，补丁=热修）。
     • 提交信息模板： <变更类型> <影响模块> <风险等级> <回滚策略>；示例：ERP-123 fix billing P1 rollback:sql_script_20241212
     • 合并记录：使用 svn:mergeinfo 管控；合并时写明“from/to 分支、JIRA 单、是否包含 DB 变更”。

2. 代码合并流程

   • 日常开发（主干为中心）
     • 开发以 trunk 为主，功能跨度较大的改动可短期使用 /branches/feature/（≤2周），每2-3天同步 trunk，避免漂移。
     • 合并回 trunk 前要求：本地编译通过、关键单元/集成用例通过、代码评审完成。
   • 发布流程（以发布分支冻结和加固）
     • 里程碑 T-10 工作日：从 trunk 切出 branches/release/x.y，进入软冻结（仅允许 bugfix / 风险可控的小改）。
     • T-5 工作日：硬冻结（仅 P0/P1 缺陷，需发布经理+QA 共同批准），开启候选版 tags/rc-vx.y.z-rcN。
     • T 日：在 release/x.y 上打正式 tag tags/vx.y.0，产出制品并归档。
     • 发布后：将 release/x.y 上的所有修复正向合并回 trunk；如未来仍需维护，转为 branches/maintenance/x.y。
   • 热修流程（生产缺陷）
     • 从 tags/vx.y.z 或 branches/release(x.y)/maintenance(x.y) 创建 branches/hotfix/vx.y.z-。
     • 修复后在 hotfix 分支完成回归与夜间批处理关键路径验证，合并回对应 release/maintenance 分支并打新 tag vx.y.(z+1)。
     • 将同一修复正向合并回 trunk 和所有仍受支持的 maintenance 分支。由配置管理员维护“修复回灌清单”，确保不遗漏、不重复。
   • 回滚策略
     • “优先前滚”原则：若可快速修复，优先热修发版；确需回滚时，回滚到上一个稳定 tag，对应 DB 变更需有 down 脚本或补偿脚本并预演通过。
   • 冻结节奏与变更准入
     • 软冻结：准入 P2 及以上缺陷修复、低风险配置变更；需要代码评审+冒烟通过。
     • 硬冻结：仅 P0/P1 生产阻断类问题；需发布经理、QA 负责人、模块 Owner 三方批准。

3. 冲突解决机制

   • 预防为主
     • 模块代码所有权（Code Owners）：强耦合模块明确 Owner，跨模块改动需提前技术评审与设计评审。
     • 频繁同步：长期分支（release/maintenance）上修复需每日正向合并回 trunk；特性分支每2-3天同步 trunk。
     • 提前评审数据与脚本：涉及 DB Schema/夜间批处理的变更必须附影响评估与回滚脚本。
   • 合并前检查清单
     • 合并影响面说明、冲突列表、配置/脚本差异、是否需要重放数据/重跑批处理、CI 结果链接。
   • 合并执行与回退
     • 先本地演练合并并编译，通过后在 CI 集成分支验证；合并失败或 CI 变红，责任人 4 小时内修复或回退。
     • 冲突争议升级：模块 Owner → 架构师 → 发布经理三级仲裁，最大 1 工作日内定论。

4. 质量保证措施

   • CI 渐进式引入（Jenkins/GitLab CI 均可）
     • 阶段1（1-2 个月）：trunk 与 release 分支启用构建+单元冒烟+静态分析（Checkstyle/SpotBugs/PMD）+依赖漏洞扫描；制品入库（Nexus/Artifactory）。
     • 阶段2（3-4 个月）：关键回归用例集成（优先覆盖夜间批处理关键路径、账务/库存等高风险模块），引入数据库迁移脚本 dry-run（Liquibase/Flyway）。
     • 阶段3（5-6 个月）：增加集成测试环境的批处理仿真任务（定时触发），基线数据快照+匿名化；引入变更影响面自动化检查与覆盖率门槛。
   • 门禁与质量阈值
     • trunk 与 release 分支开启质量红线：编译必过、关键回归集必过、静态扫描高危缺陷为零、数据库迁移脚本校验必过。
     • 构建变红 SLA：trunk 2 小时内恢复、release 分支 4 小时内恢复。
   • 代码评审
     • 双人评审制：至少 1 名模块 Owner+1 名开发者；DB/批处理变更需额外 QA 参与评审。
   • 版本与制品管理
     • 每次合并产出不可变制品，tag 与制品一一对应；发布说明包含变更列表、影响评估与回滚指引。

附：SVN → Git 平滑迁移方案（概要）

• 阶段0：准备
  • 选型与搭建：Git 托管（GitLab/GitHub Enterprise/Gitea）、Runner、权限与保护分支策略。
  • 历史评估：SVN 仓库体量、分支/tag 规则、二进制与大文件清点（必要时引入 Git LFS）。
• 阶段1：镜像与验证（双轨运行）
  • 建立只读 Git 镜像（svn2git/Reposurgeon），定时增量同步。
  • 在镜像上跑同样的 CI 流水线，确保构建与制品一致性；修复差异。
• 阶段2：试点
  • 选定非关键模块转入 Git 工作流（保护分支：main、release/、maintenance/；MR 合并+强制评审+CI 门禁）。
  • 梳理提交信息与分支命名规范，完善模板与钩子。
• 阶段3：正式切换
  • 冻结窗口（例如 24-48 小时）：冻结 SVN 合并，只接受 P0，通过“变更单+双写计划”控制。
  • 最终全量迁移：停止 SVN 提交，完成最后一次增量迁移与校验，解除 Git 只读，启用 Git 为唯一写入端。
  • 保存 SVN 只读档案，用于历史审计。
• 阶段4：稳定期
  • 加强监控与支持，1-2 个发布周期后下线 SVN CI 与双轨策略。

RACI 角色（简版）

• 迁移工具与流程：SCM 管理员(R)、架构师(A)、CI 工程师(C)、开发/QA(I)
• 切换窗口与回退预案：发布经理(A)、SCM 管理员(R)、架构师(C)、业务负责人(C)、全员(I)
• 分支保护与权限：SCM 管理员(R)、安全负责人(C)、发布经理(A)
• 历史核对与验证：CI 工程师(R)、QA(A)、模块 Owner(C)

风险控制

• 潜在风险识别
  • 高耦合导致合并冲突频发、隐形依赖引起回归。
  • 自动化不足导致冻结期 bug 外溢；夜间批处理在测试环境不可复现实数据问题。
  • 热修回灌遗漏或顺序错误；多维护分支的修复漂移。
  • SVN→Git 迁移期间双轨不一致、历史丢失或 LFS 管理不当导致仓库膨胀。
• 预防和应对措施
  • 模块边界与所有权：跨模块改动强制设计评审；制定“变更影响矩阵”。
  • 回归用例优先级：优先覆盖夜间批处理、结算对账、库存扣减等关键路径；设立“关键回归最小集”作为门禁。
  • 回灌清单与看板：每个热修生成回灌任务，按“修复源→目标分支”矩阵打勾校验；每周审计。
  • 分支权限与钩子：禁止直接对 release/maintenance 提交，必须通过合并；提交信息校验钩子与禁止大文件规则。
  • 双轨校验：迁移演练期保留 SVN 与 Git CI 结果比对，构建产物 checksum 校验。
• 监控和优化建议
  • 指标：构建成功率、平均修复时间(MTTR)、变更失败率、热修频次、未回灌项数、分支存活时长、冲突次数。
  • 节奏复盘：每次发布后召开 Release Retro，更新冻结策略与门禁阈值；每季度审查分支策略执行度。

团队协作指南

• 角色职责定义
  • 发布经理（A）：发布计划、冻结窗口、准入决策、切换与回滚拍板。
  • SCM 管理员/配置经理（R）：分支策略落地、权限与钩子、tag/制品一致性、回灌清单维护。
  • 架构师（C/A 对技术策略）：跨模块变更评审、技术风险把关、复杂冲突仲裁。
  • 模块 Owner（R）：模块内评审、合并冲突解决、回归用例补全。
  • CI/CD 工程师（R）：流水线与环境、质量门禁与可观测性。
  • QA 负责人（A 对质量）：测试策略、关键回归维护、发布验证与签收。
  • 开发（R）：实现、单测、合并自测、提交规范。
  • 业务负责人（C）：业务变更优先级与生产验证。
• 沟通协调机制
  • 冻结与发布节奏公告：T-15 公布计划，T-10 软冻结，T-5 硬冻结；每日稳定化站会 15 分钟。
  • 热修“战情室”：P0/P1 缺陷触发即时会议，明确修复、验证、回灌与发布窗口。
  • 回灌周报：列出本周热修及回灌矩阵，缺口项跟进责任人和期限。
• 工具使用规范
  • 任务跟踪与提交关联：JIRA 必填，提交信息包含 JIRA-KEY；CI 自动回填状态。
  • 制品与环境：所有发布自 CI 产出制品，不接受手工构建；测试/预发/生产三环境分离，配置外置化。
  • 数据与批处理：提供脱敏样本库与批处理仿真脚本；变更需附数据回滚或补偿方案。
  • 权限与保护：release/、maintenance/、main（Git）为保护分支，仅支持经评审的合并请求。

附录：操作要点清单

• 切 release 分支命令（SVN）
  • svn copy ^/trunk ^/branches/release/x.y -m "Cut release/x.y from trunk"
• 打标签命令（SVN）
  • svn copy ^/branches/release/x.y ^/tags/vx.y.z -m "Tag vx.y.z"
• 热修分支（SVN）
  • svn copy ^/tags/vx.y.z ^/branches/hotfix/vx.y.z-ERP-123 -m "Hotfix for ERP-123 from vx.y.z"
• 合并回灌（示例）
  • 在 hotfix 分支完成修复与验证 → 合并到 release/maintenance → 打新 tag → 正向合并回 trunk → 更新回灌清单与看板。

本方案以“主干为中心 + 发布分支稳定化 + 热修正向回灌”为骨架，配合分阶段 CI 强化与严格的冻结节奏、回灌矩阵与权限控制，能在现有 SVN 体系内快速落地，并为后续迁移到 Git 提前对齐模型与规范，降低组织与技术风险。

策略概述

• 推荐策略类型及适用性分析
  • 主干开发（Trunk-Based Development）+ 短生命周期分支 + 轻量级发布分支与热修分支
    • 适用性：多仓多服务、按需发布、强调快速热修和回滚、已有短分支与CI实践。主干保持随时可发布，减少长期分叉和回归风险；发布分支/热修分支仅在需要协调/修补现网时临时创建。
  • 每服务独立语义化版本（Semantic Versioning），以 Git 标签标记发布；跨服务协同发布仅在必要时建立临时 release/x.y 分支做冻结和验收。
  • GitLab 约束：受保护主干、必经MR与审批、Merge Trains、必需通过的流水线、CODEOWNERS 与审计开启。
• 核心原则和设计理念
  • 主干永远可部署、可回滚、可审计
  • 分支短、变更小、频繁合并，优先 Rebase + Fast-forward，启用 Merge Train 防止并发合并冲突
  • 以特性开关和向后兼容的契约（API/消息/Schema）控制发布风险
  • 发布即打标，回滚即回退到上一个已验证标签，代码层面使用 Revert 保持审计闭环
  • 热修优先从已发布标签切分，修后双向合并（回灌主干与在役发布分支）

实施步骤

1. 分支创建规范

   • 分支类型与命名
     • 主干：main（受保护，要求线性历史：Fast-forward only）
     • 特性/修复：feature//-, fix//-
     • 热修：hotfix//v-
     • 发布（必要时）：release//x.y（短期冻结，用于跨服务协调或大版本稳定）
     • 运维脚本/数据迁移：ops//-, migrate//-
   • 创建来源
     • feature/fix 分支一律从 main 切出
     • hotfix 分支从“最新生产标签”或对应 release 分支切出
     • release 分支从 main 指定版本点切出
   • 生命周期
     • 分支合并即删除；release/hotfix 分支在完成部署与回灌后删除
   • 标签与发布
     • 每服务独立标签：-vX.Y.Z（Git 标签 + GitLab Release 注记发布说明与产物）
     • 版本号策略：MAJOR（不兼容变更/协议升级）、MINOR（向后兼容新功能）、PATCH（缺陷修复/热修）

2. 代码合并流程

   • 一般变更（feature/fix）
     • 提交规范：Conventional Commits + Issue/MR 引用（如 feat(edge-gateway): ... Closes #123, MR !456）
     • MR 模板强制包含：变更类型、影响面、回滚策略、数据/协议变更说明、验证清单
     • CI 门禁（必过）：编译、单测、lint/格式化、SAST、依赖与许可证检查、前端构建与单测、后端单测与race检测、合约测试（API/Kafka Schema 对比 main）、服务合成/契约测试（可使用多项目流水线）
     • 审批：CODEOWNERS（服务Owner）+ SRE/安全（视风险级别），默认2人审批；变更较小可1+1（Owner+任一Reviewer）
     • 合并策略：Squash + Fast-forward + Merge Train（避免并发冲突；保持线性历史；1个MR=1个commit，便于回滚）
     • 部署：自动到 Staging；通过冒烟/E2E 后手动晋级到生产或灰度（Canary）
   • 热修（hotfix）
     • 分支：从生产最新标签或当前 release 分支切出 hotfix//vX.Y.Z-
     • 流水线：与一般变更同，但启用“热修通道”（缩减审批至：服务Owner + 值班SRE），生产前必须通过回归关键用例与合约检查
     • 发布：打 PATCH 标签并直接生产灰度，灰度通过后全量
     • 回灌：hotfix 合并回 main（Squash+FF）与仍在使用的 release 分支；确保主干包含 fix
   • 发布分支（大版本或多服务联动时）
     • 冻结：release//x.y 上仅接受 fix/性能/安全修复
     • 验收：完成集成回归后按服务打 -vX.Y.0 标签并发布
     • 收尾：将差异回灌 main，删除 release 分支
   • 回滚
     • 首选运维回滚：环境回退到上一个稳定标签对应的镜像与配置
     • 代码层面：对引发问题的 Squash 提交执行 git revert，保留审计；如为热修，引入 hotfix revert 并重发标签 vX.Y.(Z+1)
     • 数据/Schema 回滚：遵循“扩展-迁移-收缩（expand-migrate-contract）”，仅在支持可逆迁移时回退；否则启用降级路径与特性开关切换

3. 冲突解决机制

   • 预防
     • 强制 MR 合并前自动 Rebase onto main（GitLab Rebase 按钮 + 合并条件）
     • 启用 Merge Trains 串行合入，避免“绿测粉碎”与隐藏冲突
     • 按目录 CODEOWNERS 与路径级权限，减少高耦合区并发改动
     • 分支时限：常规分支 <= 2 个工作日；超期需拆分或提前合入可独立交付部分
   • 解决
     • 本地 rebase 解决冲突后推送（或在MR界面解决小冲突），CI 重跑验证
     • 协同变更（跨服务协议）：先更新契约（定义/IDL），下游适配通过后再切换上游行为；CI 验证前向/后向兼容

4. 质量保证措施

   • 前端（Vue3）：单测+组件快照、E2E（Cypress/Playwright）、构建产物签名、Source Map 管控、接口契约测试
   • 后端（Go + Kafka）：单测覆盖阈值、race 检查、静态分析（golangci-lint）、集成测试（容器化依赖）、Kafka Schema Registry 兼容性检查（向后/向前）
   • 跨服务：合约测试、多项目流水线触发；金丝雀发布+自动回退策略
   • 安全与合规：SAST/依赖漏洞扫描、密钥泄露检测、许可证合规
   • 审计：所有生产变更必须绑定 Issue/MR/标签与审批记录；GitLab Releases 自动生成变更日志

风险控制

• 潜在风险识别
  • 热修压力下跳过测试/审批导致二次事故
  • 跨服务不兼容（API/Kafka Schema）引发数据丢失或消费异常
  • 合并竞态导致主干短暂不稳定
  • 回滚失败（不可逆数据迁移、状态漂移）
  • 流水线不稳定影响发布效率
  • 分布式团队时区沟通延迟，窗口期内误操作
• 预防和应对措施
  • 热修通道最小但硬性门槛：关键用例回归+合约检查+Owner/SRE 双签，生产灰度强制通过再全量
  • Schema 治理：强制“向后兼容”策略与演进式迁移；CI 对比 main 的 IDL/Avro/Proto 兼容性
  • Merge Train + FF-only + 必须 Rebase，确保主干线性与绿测
  • 回滚演练：每月在预生产演练“回滚到上版本标签”和“数据迁移回退或降级路径”；变更单需填写可逆性说明
  • 流水线稳定性：缓存、并发队列、失败重试、测试隔离；对 flaky case 标注与治理指标
  • 变更分级与窗口：高风险变更要求重叠时区在岗（Owner+SRE），预留回滚窗口与扩容保障
• 监控和优化建议
  • 指标：变更前置时间、变更失败率、回滚频率、平均修复时间（MTTR）、主干绿测率、流水线通过时长
  • 质量门禁动态调优：逐步拉高覆盖率与契约测试覆盖；对高风险服务启用更严格审批
  • 事故复盘：GitLab Issue 模板沉淀根因、教训、守护策略与检测用例；将复盘项转化为 CI 规则或检查清单

团队协作指南

• 角色职责定义
  • 服务 Owner：需求澄清、架构与契约把关、代码审批、发布决策
  • 值班 SRE（7x24）：生产变更把关、发布/回滚执行、监控与告警处理
  • 开发者：短分支开发、编写测试、遵循提交与MR模板、落实回滚方案
  • 安全/合规：审查高风险依赖与敏感改动
  • 发布经理（轮值）：跨仓协调、合并顺序/窗口管理、版本公告
• 沟通协调机制
  • 在每个 MR 中引用关联 Issue 与受影响服务；跨仓联动以“协调 Issue”汇总
  • 热修/事故：启用专用频道（如 #incident-hotfix-日期），变更单与回滚预案同步在 MR/Release Note
  • 每周变更评审会（轻量）：回顾高风险变更、流水线健康、指标趋势
• 工具使用规范（GitLab）
  • 保护策略：main 与标签受保护；仅发布机器人/发布经理可打生产标签
  • 必须条件：通过流水线、最少审批人数、CODEOWNERS 强制、MR 必须 Squash、FF-only、启用 Merge Trains
  • 模板与规则：MR/变更单/复盘模板；Conventional Commits 钩子；Push Rules 禁止直接推送 main
  • 环境与发布：GitLab Environments 标记各环境部署版本；GitLab Release 用于生成发布说明并绑定产物
  • 审计：开启项目/组审计日志；使用项目访问令牌进行CI推送与受控打标

以上方案在不增加不必要复杂度的前提下，确保：主干稳定可发布、热修快速合规、回滚有据可循、跨服务契约可验证、过程全链路可审计，适配分布式团队与按需发布的实际场景。