GitHub PR Action如何确保运行合并后代码？默认行为是什么？

我太懂你遇到的这种隐性坑了——两个分支单独跑测试全过，PR还显示「可正常合并」，结果真合并上线就炸了，这种逻辑层面的合并冲突最让人头疼。咱们一步步拆解问题：

GitHub Actions的默认行为是什么？ #

首先明确：当你用pull_request触发器触发工作流时，GitHub默认会自动创建合并提交（把PR分支合并到目标分支的最新版本），然后在这个合并后的代码上执行你的测试。

但要注意：GitHub的「可合并」检测只看文件行级别的冲突（比如两个分支改了同一行代码），像你例子里这种「两个分支都往列表加元素，合并后元素数量超预期」的情况，属于逻辑冲突，GitHub是检测不出来的——这也是为什么必须靠测试来兜底。

怎么确保工作流执行的是合并后的代码？ #

其实默认行为已经帮你做了这件事，但你可以通过配置明确保障，避免踩坑：

• 用默认的actions/checkout步骤
  当你在PR工作流里使用actions/checkout时，它默认拉取的不是PR分支的代码，而是PR分支与目标分支合并后的代码。比如这个基础工作流：

  on: pull_request
  jobs:
    test-merged-code:
      runs-on: ubuntu-latest
      steps:
        - name: Checkout merged code
          uses: actions/checkout@v4
        - name: Run Python tests
          run: |
            python foo.py
            # 或者用pytest之类的测试框架
  

  这个checkout步骤会自动帮你合并目标分支和PR分支，然后在合并后的代码上跑测试，正好能提前发现你例子里的断言失败问题。

• 避免手动指定PR分支的ref
  如果你在checkout里加了ref: ${{ github.head_ref }}，那它就只会拉取PR分支的代码，而不是合并后的版本——这时候就测不到合并后的逻辑问题了，一定要避免这种配置。

为什么你的例子会出现这种问题？ #

再回到你的场景：

• master分支：my_list = [1,2]，断言长度2
• feat_a：加了0，断言长度3
• feat_b：加了3，断言长度3

两个分支都没改同一行代码，所以GitHub认为可以自动合并，但合并后列表变成[0,1,2,3]，断言长度3自然失败。这种情况只有在合并后的代码上跑测试才能发现，而GitHub Actions的默认行为正好能覆盖这个场景——只要你的测试用例足够，就能提前拦截这种问题。

总结一下：GitHub Actions在PR触发时默认就是测试合并后的代码，你不需要额外配置就能应对这种逻辑冲突场景。如果你的工作流没测出来，要么是测试用例没覆盖到，要么是checkout步骤被错误配置成只拉取PR分支代码了。

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