Skip to content
gardendocs

What is garden?

garden is source control built for agents: a managed monorepo with a git-compatible CLI.

Your checkout is a virtual filesystem backed by the server, not a local .git directory, so cloning is instant at any size. Changes are stacked commits rather than branches, and garden push doesn’t push a branch — it opens one pull request per commit. A server-side merge queue lands them.

Terminal window
curl -fsSL https://get.gardenscm.ai/install.sh | sh

It speaks git

Section titled “It speaks git”

The day-to-day verbs work with garden in front of them, and take the flags you already know:

Terminal window
garden status
garden add .
garden commit -m "fix the parser"
garden log --oneline
garden diff
garden rebase main

The git commands reference lists what is supported, what means something different, and what is deliberately absent.

What’s actually different

Section titled “What’s actually different”
git garden
Checkout Clone the whole history up front Virtual filesystem, materialised on demand
Unit of work A branch with many commits A stack of commits, one PR each
Opening a PR Push a branch, then open a PR garden push — the push is the PR
Merging You press the button A merge queue rebases, re-tests, and lands

Built for agents

Section titled “Built for agents”
  • Your agent gets the guide. garden skill install writes a “use garden, not git” guide into Claude Code, Cursor, and Codex — published here as the agent guide.
  • Symbols, not grep. Scanning a virtual filesystem is slow and expensive. garden code answers “where is this defined, who calls it” against a real index.
  • Machine-readable everything. Most read commands take --json, and garden commands describes the whole CLI as versioned JSON so an agent never scrapes --help.
  • Review is structured. Comments anchor to a commit, not a diff position, so they survive rebases. Unresolved threads block the merge — no “merge and follow up”.

Next

Section titled “Next”