gitlab通过.gitlab-ci.yml中rules（或only/except）显式配置分支触发条件，如- if: $ci_commit_branch == "main"，并确保文件存在、语法正确、runner在线且标签匹配，才能在远程分支变更时自动执行部署。
Git 远程分支本身不会自动部署，必须靠 CI/CD 系统监听分支变动并执行部署逻辑。关键不是“分支有没有能力”，而是你有没有在 .gitlab-ci.yml 或对应平台的配置中，为该分支明确声明触发条件和部署动作。
怎么让 GitLab 检测到远程分支变更就跑部署？
核心是 .gitlab-ci.yml 里的 rules 或旧版的 only/except 配置。GitLab 不会默认监听所有分支——它只响应你显式指定的分支规则。
- 用
rules更安全：例如- if: $CI_COMMIT_BRANCH == "main"表示仅当推送到main分支时才触发流水线 - 别漏掉
push事件类型：默认只响应push，但如果你还希望 MR 合并后也部署，得加- if: $CI_PIPELINE_SOURCE == "merge_request_event" - 避免用
only: [branches]这种宽泛写法：它可能意外触发非预期分支（比如dev-temp），导致测试环境被污染 - 注意通配符陷阱：如
- if: $CI_COMMIT_BRANCH =~ /^release\/.*/能匹配release/v2.1，但若正则写成/release\/.*/（缺开头锚点），可能误匹配hotfix/release/v2.1
为什么 push 到远程分支后 CI 没反应？
常见原因不是钩子没装好，而是流水线被静默跳过或根本没生成。最常踩的坑是：.gitlab-ci.yml 文件不在推送分支的根目录，或者文件语法有错导致解析失败。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 检查
CI/CD → Pipelines页面：如果列表为空，大概率是.gitlab-ci.yml缺失或路径不对；如果显示skipped，点进去看具体跳过原因（比如 rules 不匹配、runner 离线） - 确认文件编码：Windows 下用记事本保存的 YAML 可能含 BOM 头，GitLab 解析器会直接报错
YAML syntax error - Runner 必须在线且标签匹配：如果你在 job 中写了
tags: [production]，但注册的 runner 没打production标签，job 就永远 pending - 权限问题：私有项目里，如果 runner 是 shared 类型但未被项目启用，也会跳过
部署脚本里怎么安全地拉取最新代码？
不要在部署 job 里用 git pull，因为 runner 默认使用 shallow clone（深度为 1），git pull 会失败。正确做法是让 GitLab 自动 checkout 完整历史，然后直接操作工作区。
- 确保
.gitlab-ci.yml中没设GIT_DEPTH: 1（除非你确定不需要历史） - 部署到远程服务器时，别用
scp直传整个工作目录：包含.git和临时文件，体积大且不安全；应先用rsync --exclude='.git' --delete同步干净产物 - 如果部署目标是容器环境，优先构建镜像再 push：比拉源码编译更可靠，也规避了目标机缺少构建工具链的问题
- 敏感信息（如 SSH 私钥、数据库密码）绝不能硬编码在脚本里：用 GitLab 的
CI/CD → Variables配置 masked 变量，并在 job 中通过$DEPLOY_KEY引用
真正难的不是写对第一行 script:，而是让每次部署都可追溯、可中断、可回滚。比如 deploy_job 应该带明确的语义化 tag（如 v2.1.0-$(date +%s)），而不是只依赖 commit hash——后者在多人协作中很难快速定位影响范围。
