git gc --prune=now --aggressive in CI Caches
git gc repacks objects and prunes ones older than the grace period; git gc --prune=now drops all unreachable objects immediately to reclaim disk on cached runners.
On persistent runners a .git directory grows without bound as branches and rewrites pile up. gc compacts it, and --prune=now reclaims space now instead of after the default two-week grace window.
What it does
git gc consolidates loose objects into packfiles, prunes unreachable objects older than the grace period (default 2 weeks), expires reflogs, and packs refs. --prune=now drops the grace period so all currently-unreachable objects go immediately. --aggressive spends more CPU for a tighter pack; it is rarely worth it routinely.
Common usage
git gc
# reclaim everything unreachable right now
git reflog expire --expire=now --all
git gc --prune=now
# quick, only if the auto threshold is hit
git gc --auto
# tighter (slow) repack
git gc --aggressive --prune=nowOptions
| Flag | What it does |
|---|---|
| --prune=<date> | Prune unreachable objects older than <date> (now = all) |
| --no-prune | Repack but keep unreachable objects |
| --aggressive | Spend extra CPU for a more compact repository |
| --auto | Run only if enough loose objects/packs have accumulated |
| --quiet | Suppress progress output |
In CI
Reflogs keep dropped commits reachable, so run git reflog expire --expire=now --all before git gc --prune=now to actually free them. Avoid --aggressive in regular CI: it is slow and the gain is marginal. Note that a concurrent git process can race gc and leave a gc.log warning; the next operation usually clears it.
Common errors in CI
"warning: There are too many unreachable loose objects; run 'git prune' to remove them." is a hint, not a failure. "fatal: gc is already running on machine ..." means a stale gc.pid lock from a killed job; remove .git/gc.pid. "error: The last gc run reported the following ... see .git/gc.log" surfaces a prior failure; read gc.log and resolve, then it clears.