Fastlane中number_of_commits在GitHub Actions中的特殊行为解析

在使用Fastlane进行持续集成时，开发者经常会遇到一个有趣的现象：number_of_commits这个Action在本地环境和GitHub Actions环境中表现不一致。本文将深入分析这一现象的原因，并提供解决方案。

问题现象

当开发者在本地运行fastlane run number_of_commits命令时，能够正确获取当前分支的提交总数。然而，当同样的代码在GitHub Actions工作流中执行时，无论实际有多少提交，返回的结果总是1。

原因分析

这种现象的根本原因在于GitHub Actions对Pull Request的特殊处理机制。当GitHub Actions处理Pull Request时，它实际上创建了一个特殊的合并提交，这个提交包含了源分支和目标分支的合并结果。因此，从Git的角度来看，这个特殊的合并提交就是唯一的提交，导致number_of_commits返回1。

解决方案

要获取真实的提交数量，我们需要在GitHub Actions工作流中显式地检出源分支和目标分支。以下是推荐的解决方案：

1. 在GitHub Actions工作流中使用actions/checkout@v4，并设置fetch-depth: 0以确保获取完整的提交历史
2. 显式地检出源分支和目标分支

示例配置如下：

steps:
  - name: Checkout
    uses: actions/checkout@v4
    with:
      fetch-depth: 0
      lfs: true

  - name: Checkout base and head branches
    run: |
      git checkout ${{ github.event.pull_request.base.ref }}
      git checkout ${{ github.head_ref }}

技术细节

当设置fetch-depth: 0时，GitHub Actions会获取完整的仓库历史，而不是默认的浅克隆。这使得Git能够访问完整的提交历史记录。随后，通过显式检出源分支和目标分支，我们确保了Git命令能够正确计算这两个分支上的提交数量。

最佳实践

1. 在Fastlane脚本中，明确区分本地环境和CI环境的行为
2. 对于需要提交计数的场景，考虑使用环境变量来传递这个值
3. 在文档中记录这种环境差异，避免团队成员困惑

总结

理解GitHub Actions对Pull Request的特殊处理机制对于正确使用Fastlane的number_of_commitsAction至关重要。通过适当的配置，我们可以确保在CI环境中也能获取准确的提交计数，从而保证构建过程的可靠性。这种差异也提醒我们，在开发跨环境的自动化脚本时，需要充分考虑不同环境的行为差异。