Managed Git — Publishing and Reviewing Changes

Last updated: 2026-09-21

Managed Git, part 2 of 2.

← Part 1 of 2: Managed Git — Cloning Repos and Worktrees

Publishing a folder to GitHub#

A project that isn't a Git repository yet — one you created on the iPhone, or a folder you picked on a Mac or a Cloud Sandbox — shows Publish where a repository would show Review. Tap it, name the repository, choose public or private, and RepoGo creates it under your connected GitHub account and attaches it to the project you're already in. The project keeps its identity: same chats, same open tabs, same files.

The new repository is created empty, so the folder's own files become its first commit — nothing is generated into it. RepoGo commits everything present, so add a .gitignore first if the folder holds build output or dependency folders; you'll get a warning when there isn't one, and you can add it and push again.

On a Mac or a machine you run the host on, the commit uses that machine's own Git identity, and the push uses that machine's own GitHub credentials. If the identity has never been configured, RepoGo tells you which two git config --global commands to run. If the machine can't authenticate to a private repository, RepoGo says so plainly — the repository is created and the commit is saved locally, so you can sign in on that machine and push again. Publishing from the iPhone uses your RepoGo GitHub connection and needs nothing on the device.

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; other worktrees are untouched. Shared history remains on hosts that use linked worktrees.

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#

On a Mac, self-run host, or Cloud Sandbox, RepoGo starts environment.json services automatically as soon as a clone finishes — dev servers and watchers are up and running by the time you open the project. Android does not run startup services yet.

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? On a Mac, self-run host, or Cloud Sandbox, worktrees of the same repository share one copy of its history, so each additional one costs roughly the size of the working files. Android currently creates an independent full clone for each worktree, so it uses roughly clone-sized storage.

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.

Shipping map preferences#

On iPhone, Edit Profile lets you enable Tag Location on Pushes and Show Shipping Map on Profile. Both are off by default and separate from leaderboard participation. Tagging asks for location permission; pushes still work without it.

Sharing shows city-level activity on your profile and the global map, including saved and future pushes. It requires a claimed username. Exact coordinates, repository details, and individual push times are not published.