Managed Git — Cloning Repos and Worktrees

RepoGo can put a GitHub repository onto any environment for you — your paired Mac, a machine you run the RepoGo host on yourself, or a Cloud Sandbox — without you ever opening a terminal. We call these managed checkouts: RepoGo clones them, tracks them, lists them, and removes them on request.

You get to a managed checkout from the environment picker: choose an environment, tap Clone Repo, pick a GitHub account, a repository, and a branch, then choose Clone or New Worktree.

Clone vs. worktree#

Both give you a working copy of the repo. The difference is how many you can have and what branch they sit on.

Pick Clone when you just want the project on the machine. Cloning acme/web on main gives you one folder; asking again later doesn't re-download it — RepoGo fetches and updates the folder you already have.

Pick New Worktree when something is already in progress and you want a second, independent copy. Say an agent is mid-task on main and you want to try a different approach: a worktree gives you a separate folder on its own fresh branch (main-a91c4f), so both can run at the same time with no conflicts and no second full download.

Git will not let the same branch be checked out twice, which is why each worktree gets its own new branch instead of the one you picked. That's also what lets you create several worktrees from the same base branch.

Where the folders go#

RepoGo keeps managed checkouts in its own predictable place, separate from anything you cloned yourself. The layout is the same on every environment; only the root differs.

Three separate trees:

Keeping clones and worktrees in different trees is deliberate: a clone of acme/web@main and a worktree off main never collide, and either can be removed without disturbing the other.

On a paired Mac, or a machine you run the host on#

Everything lives under a plain, visible repogo folder in your home directory:

~/repogo/repos/acme/web/main            ← clone of acme/web on main
~/repogo/repos/acme/web/feature%2Flogin ← clone of the feature/login branch
~/repogo/worktrees/acme/web/main-a91c4f ← worktree, on its own new branch
~/repogo/bare/acme/web.git              ← shared history behind the worktrees

Two details worth knowing:

• Branch names with slashes are escaped in the folder name. A branch named feature/login becomes the folder feature%2Flogin, so a branch never turns into nested directories. The branch inside the checkout is the real feature/login.
• ~/repogo is not the same as ~/.repogo. The hidden ~/.repogo folder is RepoGo's own state — its settings and internal database. Your code is only ever in the visible ~/repogo.

If you run the host yourself, you can point these somewhere else with the REPOGO_REPOS_DIR, REPOGO_WORKTREES_DIR, and REPOGO_BARE_DIR environment variables before starting it.

On a Cloud Sandbox#

A Cloud Sandbox keeps clones on its persistent disk:

/vercel/sandbox/repos/acme/web/main

Same <owner>/<repo>/<branch> layout, same rules. Everything there is saved when the sandbox sleeps and restored when it wakes, so you clone once and it's still there days later.

The sandbox also has a /vercel/sandbox/internal folder — that's RepoGo's own host software, not yours. Leave it alone.

The temporary sandbox that spins up for a single task when you open a GitHub repo works differently: it's pinned to one repo at /vercel/sandbox/project for the life of that task, and isn't a managed checkout you clone into or remove.

On your iPhone#

Repositories stored on the iPhone itself aren't folders on a disk you browse — they're kept inside the app's own storage. Clone, worktree, and the folder layout above apply to Macs, your own servers, and Cloud Sandboxes.

Repos you cloned yourself#

Managed checkouts are an option, not a requirement. On a Mac you can also use Pick Folder in the environment picker to open a repository that's already on your machine, wherever it lives. RepoGo works against it exactly the same way — it just doesn't manage its lifecycle, so it won't appear under Repos or Worktrees and can't be removed from the app.

Review and publish changes#

Open Changes from a project to review every modified file before publishing it. RepoGo shows two action slots; the pull-request action changes with the current branch:

• Push & Commit commits all reviewed changes on the current branch and pushes that branch to its remote.
• Create Branch & PR appears when the project is on its default branch. Enter a new branch name and RepoGo creates and checks out that branch on the environment, commits and pushes the changes, then opens a pull request back to the default branch.
• Open Pull Request appears when the project is already on a feature branch. RepoGo stays on that branch, commits and pushes it, then opens the pull request from the current branch. It does not create an extra branch.

Branch creation, commits, and pushes happen in the real checkout on the environment where the project lives. Opening the pull request uses the GitHub account connected under Integrations; connect the repository there before using either pull-request action.

Seeing and removing checkouts#

Open an environment in the picker and you'll see its live Repos and Worktrees lists, read straight from the machine. Each entry shows its branch, whether it has uncommitted changes, and how far ahead or behind its remote it is.

Tap one to start working in it. Swipe to remove it:

• Removing a clone deletes that folder.
• Removing a worktree removes just that working copy; the shared history and your other worktrees are untouched.

Removal is permanent and takes uncommitted changes with it — push anything you want to keep first. RepoGo will only ever remove a folder inside its own managed trees; it refuses to touch anything else.

Credentials never land on disk#

When you clone, RepoGo mints a short-lived GitHub token for that one operation. The moment the clone finishes, the token is stripped out of the folder's saved remote, so nothing long-lived is written to the machine. Later operations mint a fresh token the same way, and tokens are scrubbed from any error message you see.

This is why cloning works on a machine you've never logged into GitHub from — the access comes from your GitHub connection in RepoGo, not from credentials stored on the box.

What happens right after a clone#

If the repository has an environment.json, RepoGo starts its services automatically as soon as a clone finishes — dev servers and watchers are up and running by the time you open the project.

Worktrees deliberately skip this. Several worktrees of the same repo share the same committed configuration, so starting them all would mean several services fighting over the same ports. Start what you need in a worktree yourself.

Frequently asked questions#

I cloned the same repo and branch twice — did I get two copies? No. Cloning a repo and branch you already have updates the existing folder instead of downloading it again. Worktrees are the opposite: each one is new.

Can I have main and a feature branch at the same time? Yes. Clones are per branch, so main and feature/login are two separate folders and both can be open at once.

Do worktrees use a lot of disk? No. Worktrees of the same repository share one copy of its history, so each additional one costs roughly the size of the working files.

Why is my worktree on a branch I didn't pick? Git forbids checking out one branch in two places, so each worktree is created on a new branch off the one you chose (main → main-a91c4f). Rename or push it as any other branch.

Can I move or rename these folders myself? Don't. RepoGo finds managed checkouts by their location; moving one makes it disappear from your Repos and Worktrees lists.

Next steps#

• Working in the cloud? See Cloud Sandboxes.
• Want services running the moment you clone? See environment.json.