git gc Command: Repack Repos in CI

By Daniel Zoghalchali·Latchkey

git gc packs loose objects and prunes unreachable ones to reduce repo size and speed up operations.

On runners that cache a clone across many builds, the .git directory accumulates loose objects. Running gc periodically keeps the cached repo lean and fast to fetch.

Common flags

--auto - run gc only if the repo has crossed internal thresholds (cheap to call)
--prune=<date> - prune unreachable objects older than the given date (e.g. now)
--aggressive - repack more thoroughly at higher CPU cost
--no-cruft - write pruned objects loose instead of in a cruft pack
--quiet / -q - suppress progress output

Example

shell

# Keep a cached CI checkout compact between builds
git gc --auto --prune=now

In CI

Use git gc --auto in cache-restore steps: it is nearly free when nothing is needed and only repacks when the repo has grown. Avoid --aggressive in CI unless disk size is critical, since it is CPU-heavy. Ephemeral runners rarely need gc at all.

Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

.github/workflows/ci.yml

- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached

Key takeaways

git gc --auto is a cheap no-op unless the repo actually needs repacking.
--prune=now reclaims space from unreachable objects in cached checkouts.
Skip --aggressive in CI; its CPU cost rarely pays off on disposable runners.

Frequently asked questions

git gc Command: Repack Repos in CI?