Git本身不提供A/B测试运行时能力，分支仅用于代码隔离和预发布管理；真正在应用层实现A/B测试需依赖运行时配置、特征开关与用户分流逻辑。
Git 本身不提供 A/B 测试运行时能力，分支只是代码隔离手段；真正在应用层做 A/B 测试，必须靠运行时配置 + 特征开关（Feature Flag）+ 用户分流逻辑，分支仅用于预发布阶段的代码并行管理。
为什么不能直接用 Git 分支跑线上 A/B 测试
Git 分支是静态的代码快照，不具备以下关键能力：
- 无法在同一个部署实例中动态决定某个用户看到
feature-a还是feature-b - 无法按百分比、用户 ID、设备类型等条件实时分流
- 无法收集和上报各变体的埋点数据供统计分析
- 分支合并后，历史分支代码即失效，而 A/B 实验常需长期灰度、渐进放量
强行用 git checkout feature-a 和 git checkout feature-b 切换部署，等于手动做全量灰度，既不可控、不可回溯，也违背持续交付原则。
Git 分支在 A/B 测试中的真实定位
它只承担「实验代码准备」和「环境隔离」角色，不是执行层。典型配合方式如下：
-
feature/login-v2分支开发新版登录页（含特征开关逻辑） -
feature/login-v2-variant-b分支基于前者做小改动（如按钮颜色），用于对比实验 - 两个分支都合并进
develop后，通过统一的FeatureFlagConfig控制不同用户加载哪个 UI 模块 -
release/v2.1分支打包时，确保开关配置已注入，但不开关逻辑本身不随分支变化
也就是说：分支管「代码怎么写」，运行时配置管「代码怎么跑」。
如何用 Git 支持可落地的 A/B 测试流程
关键不在分支名有多酷，而在提交内容是否包含可插拔的实验能力：
- 所有实验代码必须包裹在特征开关判断内，例如：
if (config.isInExperiment("login-ab", userId)) { renderVariantB(); } - 开关配置（如
rolloutPercentage、targetUsers）不得硬编码在分支里，应从远程配置中心加载 - 每个功能分支提交时，需同步更新对应实验的文档说明（如
docs/ab-login-v2.md），记录假设、指标、预期周期 - 禁止在
main或release/*分支中保留未关闭的实验开关，否则会污染生产行为
如果某次 PR 引入了新实验，但没附带开关控制、没写分流逻辑、没定义评估指标，那它就不是 A/B 就绪的提交 —— Git 分支再干净也没用。
真正容易被忽略的是：A/B 测试的成败不取决于你开了几个分支，而取决于你有没有把「实验意图」准确编码进运行时逻辑，并让数据反馈能闭环驱动决策。Git 只是那个帮你把意图分门别类存好的柜子，别误以为拉开柜门就能自动做实验。
