git分支本身不实现多渠道发布，需结合分支策略、构建配置与ci/cd流水线协同设计；推荐用release/stable、release/beta等前缀命名渠道分支，通过ci环境变量匹配分支名触发差异化构建与部署。
Git 分支架构本身不直接“实现”多渠道发布与部署，它只是提供了一套版本隔离机制；真正落地多渠道发布，依赖的是分支策略 + 构建配置 + CI/CD 流水线的协同设计。单纯靠 git branch 或 git checkout 是无法自动完成渠道打包、签名、分发的。
如何用分支区分发布渠道（比如 stable / beta / canary）
核心是把渠道语义映射到分支命名与保护规则上，而不是靠 Git 自身能力识别“渠道”。
- 推荐使用固定前缀，如
release/stable、release/beta、release/canary，避免用beta这类孤立名称——CI 脚本靠正则匹配分支名触发不同构建逻辑 - 每个渠道分支应受保护：禁止直接 push，只允许通过 PR 合并，且 PR 必须通过对应渠道的流水线验证（例如
release/beta需运行 UI 回归测试 + 崩溃率检查） - 不要让多个渠道共享同一分支（比如用
main同时发 stable 和 beta），否则构建产物无法溯源，灰度发布会失控
构建脚本如何根据分支名决定打包行为
CI 环境变量（如 GITHUB_HEAD_REF 或 CI_COMMIT_REF_NAME）是判断渠道的唯一可靠依据，不是靠当前工作区检出状态。
- 在 GitHub Actions 中，用
if: startsWith(github.head_ref, 'release/stable')控制 job 执行 - 构建时注入渠道标识：Webpack/Vite 里读取
process.env.CHANNEL，再动态加载不同 API 地址或功能开关配置 - Android Gradle 中可通过
git rev-parse --abbrev-ref HEAD获取当前分支，在build.gradle里做条件判断，设置不同applicationId或versionName
为什么不能只靠 git worktree 管理多渠道开发
git worktree 解决的是本地并行开发问题，不是发布渠道管理问题。它不感知 CI、不控制构建参数、不保证分支间代码隔离强度。
- 你在
worktree里切到release/beta，改完代码后仍需 commit + push 才能触发 beta 渠道构建；本地 worktree 不等于线上渠道环境 - 如果多个 worktree 指向同一分支（比如两个 worktree 都指向
release/stable），它们共享 reflog 和 HEAD，无法做到真正的渠道隔离 - CI 流水线永远以远程分支为权威源，本地 worktree 的修改若未推送，对发布流程完全无影响
真正容易被忽略的点在于：渠道差异往往藏在构建时而非代码中。同一个 commit，因分支名不同被 CI 解析成不同渠道，进而触发不同签名密钥、不同资源包、不同推送目标——这个决策链必须显式定义在 CI 配置里，不能指望 Git 自己“理解”渠道含义。
