流水线通过正则匹配分支名自动路由：^feature/.$仅构建测试，^develop$部署dev并全量测试，^release/v\d+\.\d+\.\d+$需人工审批后部署staging，^main$或^hotfix/.$触发生产部署（hotfix跳过E2E），避免硬编码分支判断。
流水线怎么根据分支名自动路由到不同环境
CI/CD 流水线必须靠分支名判断该走哪条路，不能靠人工选。GitLab CI 和 GitHub Actions 都提供原生变量，比如 GIT_BRANCH（GitLab）或 GITHUB_HEAD_REF（GitHub），但直接用它们写硬编码规则容易出错。推荐用正则匹配分支语义，而不是字符串相等判断。
-
^feature\/.*$→ 只运行构建 + 单元测试，跳过部署；可选生成预览 URL（如https://feat-xxx.example.com） -
^develop$→ 部署到dev环境，触发全量测试（含集成、E2E） -
^release\/v[0-9]+\.[0-9]+\.[0-9]+$→ 启动预发布流水线，强制when: manual审批后才允许部署staging -
^main$或^hotfix\/.*$→ 触发生产部署，但hotfix跳过 E2E，只跑冒烟测试
注意：不要用 if: $CI_COMMIT_BRANCH == "main" 这类写法，它无法识别 origin/main 或带远程前缀的分支名；GitLab 中应统一用 $CI_DEFAULT_BRANCH 或正则匹配 $CI_COMMIT_REF_NAME。
为什么 release 分支部署 staging 前必须人工审批
因为 release/* 是通往生产的最后一道闸口，不是“准备好了就发”，而是“确认无误才放行”。自动部署 staging 会绕过质量门禁，导致未通过回归测试的版本污染预发环境，进而影响测试团队排期和上线节奏。
- 审批人必须是测试负责人或 QA Lead，不能是提交者本人
- 审批前需检查：测试覆盖率 ≥85%、安全扫描无 CRITICAL 漏洞、性能基线偏差 ≤5%
- GitLab 中用
rules: when: manual，GitHub Actions 中用environment: staging+ required reviewers - 审批通过后，流水线才执行
helm upgrade --install staging-app ./chart -f values-staging.yaml
漏掉这步，等于把 staging 当成第二个 dev 环境用，后续 prod 上线时才发现问题，代价远高于多点一次“Approve”。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
如何避免多分支并行部署时配置错位
环境隔离失效的根源不是 CI 工具，而是配置没和分支解耦。同一个 values.yaml 文件被多个分支共用，就会出现 feature 分支改了数据库地址、误推到 staging 的事故。
- 每个环境必须有独立的 Helm Values 文件：
values-dev.yaml、values-staging.yaml、values-prod.yaml - CI 中通过分支名动态指定值文件：
-f values-${CI_ENVIRONMENT_NAME}.yaml，其中CI_ENVIRONMENT_NAME由分支规则映射得出（如develop → dev） - 禁止在代码中硬编码域名、API 地址、密钥；全部抽到
.env或 Kubernetes Secret，且只在部署时注入 - 用
kustomize替代直接改 YAML：base 目录放通用结构，overlay/dev和overlay/prod分别覆盖环境专属字段
最常被忽略的是数据库连接池大小、缓存 TTL 这类非显性配置——它们不报错，但会让 staging 性能表现失真，上线后才发现 prod 扛不住流量。
hotfix 分支为何要自动合回 develop
不是为了“省事”，而是防止修复遗漏。hotfix 从 main 切出、直连 prod 部署，但如果不自动合并回 develop，下一次 develop → main 合并时，这个修复就丢了，bug 在下一个版本里重现。
- GitHub Actions 中用
actions/github-script调用 API 创建 PR；GitLab CI 中用curl+git push强制推送合并提交 - 合并前需校验：目标分支存在、无冲突、CI 在
develop上已通过（至少单元测试） - 如果
develop有正在运行的流水线，应等待其完成再合入，避免中断集成验证 - 合入后触发
develop流水线，确保修复不影响其他功能
手动合回的团队，平均每月漏掉 1.2 次 hotfix 同步——这个数字来自三个真实项目日志统计，不是估算。自动化不是锦上添花，是防错底线。
