如何配置GitHub Actions仅在feature特性分支的PR上运行测试

你目前想到的「在执行步骤里加if判断」的方案不属于完全错误，但属于低效率的粗粒度实现：

• 这种写法会让工作流接收到所有分支的PR事件时，先分配runner资源、拉取代码、初始化运行环境，最后才在步骤执行阶段判断是否跳过测试，会造成不必要的CI算力浪费，在大仓库场景下还会挤占公共runner资源、拉长正常任务的排队时间。
• 这种写法存在配置冗余风险：如果后续工作流新增多个测试步骤，很容易出现部分步骤漏写if判断的问题，导致不符合分支规则的任务被误执行。

针对仅对feature/ticketno格式特性分支的PR运行测试的需求，行业通用的最佳实践是把分支判断逻辑上移到工作流全局触发层，从事件源头过滤不需要的工作流实例，根本不会为不匹配的分支创建运行任务，具体配置方式如下：

• 使用GitHub Actions原生的pull_request触发器分支匹配规则，替代步骤内的if判断，核心配置示例：

on:
  pull_request:
    # 仅监听PR的创建、代码更新、重新打开三类核心事件，排除冗余触发
    types: [opened, synchronize, reopened]
    # 精准匹配需要触发测试的分支规则
    branches:
      - 'feature/**'

• 该配置的实际效果：
  • 只有关联源分支为feature/xxx格式的PR事件，才会触发后续的测试任务流程
  • 指向master、staging等分支的PR事件，从源头就不会生成对应的工作流运行实例，无额外资源消耗
• 灵活扩展的适配说明：
  • 如果后续需要严格限制特性分支的命名规则（比如必须是feature/数字工单号格式），可以直接在branches字段调整通配符规则，比如写成'feature/[0-9]*'
  • 如果后续需要同时支持其他类型的分支触发测试（比如bugfix/*格式分支），直接在branches列表中新增匹配规则即可，不需要修改每个步骤的判断逻辑

补充说明：步骤级if判断不是完全不可用，它的适用场景是「同一个工作流需要为所有分支执行通用前置逻辑（比如代码规范扫描），仅后续特定步骤针对不同分支做差异化执行」的场景，不适合作为整个工作流的分支准入判断。

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