Git分支策略是自动化测试精准触发与安全生效的前提，需通过workflow rules限定feature分支仅运行单元和接口测试，main分支强制门禁与MR合并，release分支专注回归测试并冻结功能。
Git 分支策略本身不运行测试，但它是自动化测试能否“精准触发、安全生效”的前提。选错策略或配错规则，测试就容易漏跑、误跑、或者在错误环境里跑。
feature 分支必须隔离测试环境
开发人员在 feature/login 上提交代码，CI 流水线不该直接跑生产部署脚本，但必须运行单元测试 + 接口测试（哪怕只是本地 mock 服务）。否则问题会堆到合并前才暴露，拉长反馈周期。
- GitLab 中用
workflow: rules限定仅feature/*分支触发test阶段，禁用deploy - 避免在
.gitlab-ci.yml里写only: [feature]这种模糊匹配——GitLab 已弃用，改用if: '$CI_COMMIT_BRANCH =~ /^feature\/.*/' - 测试环境变量要和分支解耦：比如
TEST_ENV=staging不应硬编码进feature作业，而应由 CI 变量或include动态加载
main 分支的测试必须带准入门禁
main 是发布源头，它的每次变更都该是“可上线”状态。光靠人工点 Merge Request 合并按钮远远不够，必须让自动化测试成为不可绕过的门禁。
- GitLab 项目设置中启用
Require all status checks to pass before merging，并把 CI 的test和build作业名填进白名单 - 禁止
main分支直接 push：在 GitLab 设置里将main设为受保护分支，只允许通过 MR 合并 - MR 合并前自动 rebase 到最新
main，再触发一次完整测试——防止“本地过、合进去就挂”
release 分支需要冻结式测试与版本锁定
当你从 main 切出 release/v2.3.0 准备发版时，这个分支上的代码就该冻结功能，只允许修复 bug。此时测试重点不是“有没有新功能”，而是“有没有引入回归”。
- 在
.gitlab-ci.yml中为release/*单独定义regression-test作业，跳过耗时的 E2E 或性能测试，专注已知路径的冒烟用例 - 使用
artifacts:expire_in: 1 week显式保留本次 release 的构建产物（如bin/app-v2.3.0），避免被后续流水线清理掉 - 版本号必须从 Git tag 或
CI_COMMIT_TAG提取，而不是写死在脚本里；否则release/v2.3.0分支上打的 tag 可能和实际构建产物对不上
最容易被忽略的是：分支策略和测试的耦合点不在 YAML 文件里，而在 GitLab 项目的「Protected Branches」和「Merge Request Approvals」设置中。配置错了，再严谨的 .gitlab-ci.yml 也拦不住一条 git push --force 直接砸进 main。
