git push options 不能直接触发 ci 流水线，只能控制流水线行为（如跳过、传参），前提是 git 服务（如 gitlab）支持且已启用 push rules 白名单；github 不原生支持该功能。
Git push options 能直接触发 CI 流水线，但前提是你的 Git 服务（如 GitLab、GitHub Actions 配合自建 runner）和 CI 系统明确支持 pushOption 且已配置白名单——不是所有平台默认开通，也不是所有选项名都叫 ci.skip。
GitLab 中用 git push --push-option 触发特定流水线
GitLab 从 12.0 开始支持 pushOption，但只认白名单内的键值对（比如 ci.skip、ci.pipeline=ci-test），且必须在项目设置里开启「Push Rules」中的「Allow usage of push options」。
- 要跳过流水线？用
git push --push-option=ci.skip origin main（注意：不是--push-option="ci.skip"带引号，Git 会把引号当字面量传给服务端） - 要指定 pipeline 变量？用
git push --push-option=ci.variable="ENV=staging" origin feature/login，然后在.gitlab-ci.yml里用$CI_PUSH_OPTION_CI_VARIABLE读取 - 多个 option 要重复写
--push-option，不能合并：错误写法--push-option="a=1,b=2"；正确写法--push-option=a=1 --push-option=b=2
GitHub 不原生支持 pushOption，但可用 workflow_dispatch + commit tag 替代
GitHub Actions 没有 pushOption 接口，官方也不计划加。想在 push 时“带参数”触发某条流水线，得换思路：
- 在
.github/workflows/ci.yml里用on: workflow_dispatch:定义输入参数，再配合git push附带特殊 commit message 或 tag，比如git commit -m "[ci:test]" && git push，然后用on: push: paths:或commit_message条件过滤 - 更可靠的做法是弃用 push 触发，改用
gh workflow run ci.yml -f ENV=prod（需安装 GitHub CLI），这样参数传递干净、可审计 - 别依赖
git push -o向 GitHub 传参——它会被静默忽略，且不报错，容易误以为成功
CI 配置里读取 push option 的常见陷阱
即使 Git 服务转发了 option，CI 脚本也未必能直接拿到。GitLab 把它们映射成环境变量，但命名规则固定：CI_PUSH_OPTION_<key></key> 全大写、点号转下划线、非字母数字全丢弃。例如 --push-option=ci.pipeline=build-fast → 环境变量名是 CI_PUSH_OPTION_CI_PIPELINE，值为 build-fast。
- 在
.gitlab-ci.yml中不能直接写if: $CI_PUSH_OPTION_CI_PIPELINE == "build-fast"，因为未定义时变量为空字符串，比较会失败；应写成if: '$CI_PUSH_OPTION_CI_PIPELINE == "build-fast"'（单引号防空展开） - 如果 key 含小写字母或点号（如
my.option），GitLab 会转成CI_PUSH_OPTION_MY_OPTION，不是MYOPTION，大小写敏感 - GitLab Runner 13.0+ 才保证完整传递 option；旧版可能截断或丢弃含特殊字符的 value
真正麻烦的是跨平台一致性——GitLab 支持 push option 是实打实的功能，GitHub 是绕路方案，而 Bitbucket Server 目前根本不支持。如果你的团队混用平台，别把关键逻辑绑死在 --push-option 上；优先考虑用分支命名规范（如 ci-staging/*）或专用 tag（如 v1.2.3+test）来触发行为，兼容性更好，也更容易 debug。
