Git integration
Studio's header Git button turns version control into buttons instead of a terminal — track, publish, sync, sign in — plus the zero-repo path that gets untracked tests onto GitHub and into CI.
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.
Studio's own folders never count as changes and never go into a commit, whether from
Sync now, auto-sync, Save changes or the agent's autopilot: the run archive, chat
attachments, the reporter's offline upload queue, page screenshots, the SDK's local .testrelic-report/, ctrf/ctrf-report.json
and the .playwright-mcp snapshots. .testrelic/testrelic-config.json is still committed.
Every 5 minutes — only fires when the tree is clean and the pull can fast-forward; anything else pauses with a quiet badge instead of a merge behind your back.
A dirty tree blocks sync until you clear it here — stages everything, commits with a fixed message. Not a commit-authoring tool: no message box, no partial staging.
Discard, Undo and switching branches
Throwing work away is undoable:
- Discarding changes in Changes, for example with Discard all…, saves the files in a restore point first, new files included, so Undo, or History → Journal, can bring them back.
- Switching branches with uncommitted edits asks what to do with them: Take them with me, Shelve them and switch (restored in one click from Shelved work), Commit them first, or Throw them away. Throwing them away drops edits to tracked files, and Undo brings them back. Untracked and ignored files stay in the folder; if the other branch has a file of the same name, the switch stops and nothing changes.
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 -ufor a branch that's never gone online.
This folder has no version control yet.
Runs git init, writes a .gitignore, and saves a first snapshot.
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:
- Creates a new private GitHub repo under your account.
- Wires it as the project's
origin. - Pushes, authenticating with a one-shot header — the token is never written into
.git/configor 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.
Tracked locally — this branch has never gone online.
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.
Push rejected — the remote needs authentication.
Hands the token to your machine's own credential store via git credential approve— never persisted by Studio, never in a command's argument list.
ssh:// or key-file? Sign-in can't fix that — Studio routes you to Ask the agent instead (remote address redacted).