Git integration

Studio has its own Git button in the header, immediately left of your org chip. It tracks the workspace's repo and keeps it in sync with its online copy — and it's also where setup happens for a project that doesn't have any of that yet, so a manual tester is never left at a dead end because there's no terminal to fall back to.

Everyday sync

Once a repo has a remote, the button shows how it compares — ahead, behind, or up to date — with two ways to reconcile:

• Sync now — pulls (fast-forward only, never a merge) and pushes (never forced).
• Auto-sync — a per-workspace toggle that runs the same sync on a timer (every 2, 5, or 15 minutes). It only fires when the tree is clean and the pull can fast-forward; anything else pauses with a quiet badge instead of risking a merge behind your back.

A dirty tree blocks both until you clear it with Save changes — a bounded escape hatch that stages everything and commits with a fixed message. It's deliberately not a commit-authoring tool (no message box, no partial staging); it exists only to get past the refusal.

Setup, from zero

A folder with no version control, or a repo with no online copy yet, used to render as a greyed-out chip with the reason in a tooltip. Now each state gets an actual button:

• No repo — "Start tracking changes" runs git init, writes a .gitignore, and saves a first snapshot.
• Repo, no remote — an address field plus Publish, which is git push -u for a branch that's never gone online.

Publish to GitHub — the zero-repo path

If a project has no remote and GitHub is connected, the Pipelines tab's empty state offers a shortcut that skips the address field entirely: Publish to GitHub (private). One click:

1. Creates a new private GitHub repo under your account.
2. Wires it as the project's origin.
3. Pushes, authenticating with a one-shot header — the token is never written into .git/config or the remote URL, and any error shown back to you has the secret scrubbed out.

On success, Studio seeds the chat to set up CI on the fresh repo — generate the workflow file, set the TestRelic secrets, and trigger the first run — so the path from "no repo, no CI" to a green pipeline run stays inside Studio the whole way.

Signing in to an existing remote

Studio disables every interactive git credential prompt on purpose — it has no terminal to show one in, and a prompt that hangs would wedge the Git button for the rest of the session. That used to mean a remote requiring auth was simply unreachable. Sign in closes the gap: give it a username and an access token, and it hands them to git credential approve — your machine's own credential store (Credential Manager on Windows, Keychain on macOS), the same helper git itself would use. Studio verifies the credential against the remote before keeping it, and erases it again if the remote rejects it, so a typo can't leave a stale token behind. The token travels on git's stdin only — never in a command's argument list, never persisted by Studio itself.

Not every refusal is a sign-in problem. An ssh:// or key-file remote can't be fixed with a token, so Studio routes that case to Ask the agent instead of the sign-in form — diagnosis only, with the remote address redacted before it ever reaches the chat transcript.

Next steps

→ Pipelines · Overview