为何相同代码在CircleCI与GitHub Actions中执行结果不同？

首先要澄清一个误区：日志里显示的命令执行顺序看起来颠倒，其实只是shell调试输出（set -x）的格式差异，GitHub Actions和CircleCI用的shell环境在打印管道命令的执行顺序时显示方式不同，但管道的实际执行逻辑是一致的——都是git diff-tree先输出内容，再传给grep处理。真正导致结果不同的核心原因是两个环境中git仓库的状态不一致。

为什么会出现结果差异？ #

最常见的原因是GitHub Actions默认的代码检出行为和CircleCI不同：

• CircleCI默认会拉取完整的仓库历史，或者至少包含当前commit的父节点，这样git diff-tree --no-commit-id --name-only -r HEAD能正确输出上一次提交中变更的文件列表。
• GitHub Actions的actions/checkout动作默认使用浅克隆（shallow clone），只拉取最新的1个commit（fetch-depth: 1），这时候HEAD没有父节点，git diff-tree不会输出任何内容，自然grep找不到目标文件，最终返回0。

验证这个问题的方法 #

在GitHub Actions的工作流中，在执行你的脚本之前，添加一个步骤查看git仓库状态：

- name: Check git history and diff output
  run: |
    git log --oneline
    git diff-tree --no-commit-id --name-only -r HEAD

如果输出里只有1条commit记录，且git diff-tree没有任何输出，那就坐实了是浅克隆的问题。

解决方案 #

修改你的actions/checkout步骤，指定拉取足够的提交历史：

• 如果你需要完整仓库历史，使用fetch-depth: 0：

- uses: actions/checkout@v4
  with:
    fetch-depth: 0

• 如果只需要对比上一次提交，拉取2个commit即可（更高效）：

- uses: actions/checkout@v4
  with:
    fetch-depth: 2

这样git diff-tree就能正确输出上一次提交的变更文件列表，grep就能找到目标文件，最终FILE_IN_LAST_COMMIT会正确返回1，和CircleCI的结果一致。

额外提示 #

如果你的脚本是要判断当前提交是否修改了指定文件，也可以用更直接的git diff命令替代，避免依赖diff-tree的行为：

FILE_IN_LAST_COMMIT=$(git diff --name-only HEAD^ HEAD | grep -Fxq "${FILE_PATH}" && echo 1 || echo 0)

这个命令逻辑更清晰，不过同样需要确保HEAD^存在，也就是仓库至少有2个提交历史。

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