GitHub PR意外触发Push工作流，如何确保仅Master分支推送触发部署？

问题背景 #

我维护着两个GitHub Actions工作流，配置分别如下：

Deploy Staging API & Web #

name: Deploy Staging API & Web

on:
  push:
    branches:
      - master

Build Api #

name: Build Api

on:
  pull_request:
    branches:
      - master
      - release

最近从release-10-19分支向release分支创建Pull Request时，意外触发了Deploy Staging API & Web的push事件。按照配置，这个工作流应该只在代码推送到master分支时才运行，请问问题出在哪？怎么修复？

原因排查 #

1. 分支间工作流配置不一致
   GitHub Actions会执行触发事件所在分支的工作流文件。如果你的release分支里，Deploy Staging API & Web的配置被修改过（比如把branches改成了release），那么当PR合并到release分支时，push事件就会触发该分支下的这个工作流——这是最常见的原因。

2. 误触发master分支推送
   创建PR过程中如果不小心执行了向master分支推送代码的操作（比如误合并、自动化脚本同步），也会触发这个工作流。

3. 分支匹配规则的隐性问题
   虽然你写的是精确匹配master，但如果工作流里还有其他未注意的触发条件（比如标签触发、反向忽略规则），也可能导致意外触发，但这种情况概率很低。

修复方案 #

1. 统一所有分支的工作流配置
   检查release分支中的Deploy Staging API & Web工作流文件，确保它的触发规则和master分支一致：

   on:
     push:
       branches:
         - master
   

   要是不同分支需要不同部署逻辑，建议单独创建工作流文件，不要在同一个文件里来回修改。

2. 用完整分支引用强化精确匹配
   为了彻底避免分支名称的模糊匹配，可以直接使用完整的分支引用路径，明确指定只触发master分支的推送：

   on:
     push:
       branches:
         - 'refs/heads/master'
   

3. 添加分支验证的双重保障
   在工作流的job里额外加一个if条件，强制验证触发分支确实是master，就算触发规则出问题，这个条件也能拦住：

   name: Deploy Staging API & Web
   
   on:
     push:
       branches:
         - master
   
   jobs:
     deploy:
       runs-on: ubuntu-latest
       if: github.ref == 'refs/heads/master'
       steps:
         # 你的部署步骤
   

4. 排查自动化工具
   检查仓库有没有关联GitHub Apps、自定义脚本之类的自动化工具，会不会在PR创建时自动往master分支推代码，有的话调整对应的逻辑。

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