Use case · CI/CD
Cut the git-status tax on every job.
Ephemeral runners clone a big repo and then run git status a dozen
times across linting, formatting, and changed-file detection. gity's oneshot mode
warms a cache for a single run and disappears when the job ends.
The problem
CI is where slow Git compounds. A fresh runner has no warm caches, so the first
git status is always a cold, full-tree walk. Then every step that
inspects the working tree — lint-staged, prettier, a monorepo build graph,
changed-file heuristics — pays that cost again. On a large checkout, those seconds
add up across thousands of pipeline runs a day.
How gity fixes it — without leaving a daemon behind
A persistent background daemon makes sense on a developer laptop, not on a runner that is destroyed after each job. gity handles this with oneshot mode:
# run one CI job with acceleration, then exit cleanly
gity daemon oneshot -- \
bash -c 'git status && npm run lint && npm run build' gity daemon oneshot starts the watcher and cache for the duration of
the wrapped command, serves the fsmonitor protocol to every Git call inside it, and
tears everything down when the command returns. No stray process, no cleanup step,
nothing to remember to stop.
Fits any runner
- Single static binary. Drops into container images and self-hosted runners alike.
- No admin privileges. gity is user-space; it needs no kernel module and no root.
- No cloud dependency. It talks to the local filesystem and Git — nothing leaves the runner.
Frequently asked
Doesn't a daemon defeat the point of an ephemeral runner?
That's exactly why gity ships oneshot mode. `gity daemon oneshot` runs the acceleration for the duration of one job and exits when the job ends — nothing persists on the runner, no cleanup step required.
Where does gity help most in a pipeline?
Any stage that runs `git status`, `git diff`, or tools that shell out to them — linters, formatters, changed-file detection, and monorepo build-graph tools. The bigger the checkout, the more each of those calls costs without gity.
How do I add it to my CI config?
Install gity in the runner image (a single portable binary), then wrap your git-heavy steps with `gity daemon oneshot`. Because it is one static binary, it drops into container images and self-hosted runners the same way.
Get gity
Try gity on your biggest repo.
One command to install, one to register, and your monorepo starts feeling like a tiny one. MIT-licensed and free to use.