Fetch only the repository history a job needs

Limit checkout depth and fetched refs to the comparisons or release history the job actually consumes.

Prompt

Evaluate and apply this CI technique to my repository: Fetch only the repository history a job needs.

Limit checkout depth and fetched refs to the comparisons or release history the job actually consumes.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/fetch-needed-history.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How companies used this technique

Read what each company changed and follow the original sources.

Give each checkout only the files and history it uses

Linear capped fetch depth, removed checkout from jobs that never used a working tree, and used sparse, blobless checkouts where it diffs paths. Capping fetch depth took the slowest change-detection gate from 94 to 20 seconds; removing checkout from jobs that never needed a working tree took them from 27 to 7 seconds.

The median duration of the change-detection job fell from 26 to 8 seconds, p90 from 31 to 12 seconds, and the slowest run from 138 to 37 seconds. Source

Use it when: A job uses only GitHub API metadata or a bounded subset of the repository.
Before applying it: Resolve merge bases, local actions, hashFiles and indirect scripts first. API-only jobs need an explicit repository context; history-dependent checks must retain enough history.

Fetch only the release history the job consumes

The workspace test workflow removed fetch-depth: 0 while preserving the triggering workflow’s head SHA. Release publishing now fetches only main’s history, deepening it in batches without tags.

Release publishing deepens main’s history in batches of 50 commits, without tags. Source

Use it when: Tests consume a source tree without history-based versioning or change detection.
Before applying it: Test tags and ancestry before giving release automation a shallow checkout.

Check out only the history the job reads

Four lint and test workflows in frontier-evals switched from a full-history checkout to a single commit, and three of them stopped downloading LFS files.

Four workflows check out one commit, and the three lint workflows stopped fetching LFS files Source

Use it when: Checkout steps fetch full history or LFS files that the job never reads.
Before applying it: Jobs that compute versions, changelogs or diffs from Git history still need full history.

Fetch the comparison, not every branch

Stripe iOS replaced a fetch that could pull every branch with a shallow checkout of the PR head followed by progressively deeper fetches of only the PR and master histories until their merge base resolves.

Some jobs had spent up to 30+ minutes fetching history; in Stripe’s combined CI runs with the related changes, lint went from about 7 to about 6 minutes. Source

Use it when: Checkout dominates CI, but lint or affected-target selection needs history.
Before applying it: Change detection needs a verified comparison base. Validate the PR head, the base and the merged tree, and run the full check whenever the base is ambiguous.

How companies used this technique

Give each checkout only the files and history it uses

Fetch only the release history the job consumes

Check out only the history the job reads

Fetch the comparison, not every branch

Related techniques

Keep full history and download old blobs on demand

Serve checkouts from pre-warmed repository clones

Bake stable dependencies into runner images

Company Playbooks

Related guides

Filter workflows by changed files

Cancel superseded CI runs