Managed Git — Publishing and Reviewing Changes

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#

On iPhone and iPad, all folders in the Changes tree start expanded. Refreshes that only update change counts preserve your expanded or collapsed folders; a changed file list expands all folders again. The trailing toolbar button expands or collapses all folders. If more than half the folders are expanded, it collapses all; otherwise, it expands all. The diagonal arrow icon shows the next action.

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#

Profile settings include Tag Location on Pushes and Show Shipping Map on Profile, both off by default. They are independent of leaderboard participation. These settings are currently available in the iPhone app.

Enabling tagging on iPhone requests permission to use location while using RepoGo. Permission applies to that device; an account preference does not grant location access on another device. If access is denied, the profile offers a Settings link. Sharing is a separate choice intended to show approximate areas, keeping exact locations private.

With updated iPhone, Mac host and spine versions, tagging records a location only for a successful push through the Mac app host or an on-device iPhone repository. Missing permission or unavailable location does not block Git. Pending location reports retry after a connection interruption; changing profile settings can invalidate an unsaved tag. On iPhone, personal and public shipping maps open with a wide regional view centered on the first location. Paging between locations or tapping a pin restores that wide view, preserving your zoom if you are farther out.

On iPhone, swipe the location details or use the page dots to switch locations. Dates appear beneath the city on your personal map, and commit counts appear beneath the diff totals, both in muted text. A single location has no page dots.