git不直接支持灰度发布，需通过分支策略（如env/prod-canary）、配置管理（argocd同步）与流量控制（nginx ingress注解）协同实现；灰度分支须从稳定tag创建、独立于master，并配置canary注解以触发流量分流。
git 本身不直接支持灰度发布，它只是版本控制工具；灰度发布靠的是「分支策略 + 配置管理 + 流量控制」三者协同。你用 git 建分支、打 tag、推配置，但真正把流量切到新版本的，是 ArgoCD、NGINX Ingress 或服务网格。
下面直说实操关键点，不绕弯。
怎么用 git 分支支撑灰度发布（不是“怎么写代码”，而是“怎么组织分支”）
核心不是多分支本身，而是分支如何映射到环境与流量。常见错误是：把 dev、test、master 当成环境代称，结果灰度时不敢动 master，又不敢在 dev 上修线上 bug。
- 必须区分「功能分支」和「环境分支」：
feature/login-v2是功能分支，env/staging、env/prod-canary才是灰度所需的环境分支 -
master不该直接对应生产环境，而应只作为「基线配置主干」——所有环境分支都从它派生，但不直接部署它 - 灰度分支命名要有可识别性，比如
release/1.5.0-canary或env/prod-10percent，避免用模糊词如gray、beta - 每次灰度前，必须基于当前
master的某个稳定tag拉新分支，而不是从dev合并——否则会带入未验证代码
为什么不能直接在 master 上做灰度配置变更
因为 master 是基线，不是发布通道。你在 master 上改了 ingress.yaml 的 canary-by-header 规则，等于所有环境同步生效，灰度就失控了。
- ArgoCD 同步的是分支内容，不是 commit 差异——一旦
master被 push，所有监听它的集群立刻拉取，没商量 - 紧急修复时，如果灰度分支和
master混在一起，你没法单独回滚灰度配置而不影响基线 - GitLab CI 的审批节点（如
production-approval）必须绑定到具体灰度分支，而不是master的任意提交
git tag 和 release 分支在灰度中的真实作用
tag 不是发布动作，而是发布快照的锚点；release 分支不是用来长期维护的，而是灰度前的「最后校验层」。
GitCode API Usage
下载
简单易用的 GitCode API SKILL，提供 CLI 和轻量级 Python SDK 两种调用方式，用于与 GitCode 的 REST API 进行交互。支持加密访问令牌、异步调用以及完善的类型提示。 - 文档：https://gitcode-api.readthedocs.io/ - PyPI 页面：https://pypi.org/project/gitcode-api - GitHub 仓库：https://github.com/Trenza1ore/GitCode-API
- 灰度开始前，先从
develop或main创建release/1.5.0分支，只允许合入hotfix/*类 PR，禁止新功能 - 灰度验证通过后，在
release/1.5.0的最终 commit 上打附注tag：git tag -a v1.5.0 -m "prod-canary passed, rollout to 100% scheduled" - 全量发布时，不是 merge
release/1.5.0到master，而是让 ArgoCD 把master的app-deployment.yaml中镜像 tag 更新为v1.5.0，再触发同步 - 灰度失败要回滚？删掉灰度分支、恢复
env/prod-canary到上一个tag对应的 commit 即可，不用碰master
GitLab CLI（glab）自动化灰度分支操作的关键命令
手动建分支、改 YAML、push，容易漏步骤或拼错路径。用 glab 把流程固化，重点不是“会不会用”，而是“哪几步不能省”。
- 创建灰度分支并切换：
glab branch create env/prod-canary-1.5.0 --start-point=refs/tags/v1.4.2 - 批量替换配置中的镜像版本（别手改）：
sed -i '' 's/image:.*$/image: registry.example.com/app:v1.5.0-canary/' k8s/deployment.yaml - 提交并推送（带描述，供 ArgoCD 解析）：
git commit -am "chore: update image for canary rollout v1.5.0"; git push origin env/prod-canary-1.5.0 - 触发 ArgoCD 同步（非必需，但推荐）：
glab api --method POST "/apis/argoproj.io/v1alpha1/namespaces/argocd/applications/myapp?action=refresh"
最容易被忽略的一点：灰度分支的 k8s/ingress.yaml 必须启用 nginx.ingress.kubernetes.io/canary: "true" 且配套设置 canary-by-header 或 canary-weight，否则 ArgoCD 同步后，Ingress controller 根本不识别这是灰度规则。
