Can you use the git commit count as the build number, and what breaks it: shallow clones, squashes, rebases and multiple branches?

The commit count (git rev-list --count HEAD) is a tempting build number: it needs no server state and increases with every commit. It is only as trustworthy as the history it counts, and the check shows two ways it fails. A CI checkout with --depth 1 (the default for many providers, to save time) counts 1 where the full history counts 5, and after git fetch --unshallow it is 5 again, so an unconfigured runner would submit build 1 and be rejected, or worse, accepted for a new version. And the count is not monotonic: squashing three commits made it fall from 5 to 3, and rebasing, force pushes or counting from a different branch do the same. App Store Connect needs uploads to be unique and increasing per version (Q481), so a number that can fall is a latent rejection.

Safer options, in rising independence from git: the CI run number (monotonic per workflow, but a different workflow or provider resets it), a timestamp such as YYYYMMDDHHMM (monotonic if clocks are right, fits as dotted integers), or a counter you own (a small service or the highest build App Store Connect reports plus one, fetched through the API, Q480). Whatever you choose: compute it in one place, once per pipeline run, write it to the build settings (CURRENT_PROJECT_VERSION) instead of editing the project file, tag the commit with version and build, and fetch full history (fetch-depth: 0 in GitHub Actions, --unshallow otherwise) wherever you count commits or run git describe. Only local repositories were used in the check; provider-specific defaults should be read from your CI’s documentation.