GitHub Actions条件判断失效：非指定分支仍触发任务

问题分析 #

你遇到的两个核心问题：

1. 非目标分支（dog1）触发任务，说明原分支过滤条件存在逻辑漏洞
2. 合并特性分支到cat1时任务被跳过，根源是合并场景下github.ref_name的取值不符合预期——比如PR合并事件中，github.ref_name对应源分支而非目标分支，或部分特殊事件中该变量为空

可行解决方案 #

方案1：兼容推送与PR合并场景的条件 #

如果工作流同时监听push和pull_request事件，可通过区分事件类型来精准过滤：

jobs:
  target-job:
    runs-on: ubuntu-latest
    if: >
      (github.event_name == 'push' && (github.ref_name == 'cat1' || startsWith(github.ref_name, 'cat2'))) ||
      (github.event_name == 'pull_request' && (github.event.pull_request.base.ref == 'cat1' || startsWith(github.event.pull_request.base.ref, 'cat2')))
    steps:
      - name: 输出分支信息
        run: echo "当前分支: ${{ github.ref_name }}, 目标分支: ${{ github.event.pull_request.base.ref }}"

• 针对push事件：直接判断当前推送的分支名
• 针对pull_request事件：判断PR的目标分支（而非源分支）是否符合要求

方案2：用github.ref做更稳定的判断 #

github.ref是完整的分支引用（格式如refs/heads/cat1），比github.ref_name更稳定，不会出现空值情况，适用于所有分支相关事件：

jobs:
  target-job:
    runs-on: ubuntu-latest
    if: >
      github.ref == 'refs/heads/cat1' ||
      startsWith(github.ref, 'refs/heads/cat2')
    steps:
      - name: 输出完整引用
        run: echo "当前引用: ${{ github.ref }}"

这个写法的优势：

• 覆盖所有分支推送场景，包括合并后的触发事件
• 彻底避免github.ref_name为空或取值错误的问题
• 逻辑简洁，无需额外判断事件类型

原问题的具体诱因 #

• dog1分支触发任务：大概率是原条件的逻辑错误（比如运算符误用、字符串匹配错误），用github.ref的写法可彻底规避这类问题
• 合并到cat1时任务被跳过：若合并是通过PR触发，原条件仅判断了源分支的github.ref_name，未考虑目标分支，方案1的PR分支判断可解决该问题

内容的提问来源于stack exchange，提问作者DevopitionBro