Git in Studio Code
Where your files actually are, what a commit does, and the three ways the work gets off this machine. Worth five minutes before a long project, because the one thing that is not obvious is the one that matters: a commit and a published repository are different events, and only one of them happens on its own.
Where the files are
Each project gets a container and a volume of its own. The container is started when a command needs it and stopped after fifteen minutes idle; the volume — every file, node_modules, the whole .gitdirectory — survives that untouched and is only destroyed when the project is deleted.
The volume is not a folder on your computer and it is not a folder on the server’s filesystem that you can browse. That is the fact behind most of this page: looking around the server for your code will not find it, and nothing about the work reaches anywhere else unless you send it.
Sessions do not change this. A project has one workspace, and every session in it shares those files, that node_modules and that git history. Starting a new session gives you a fresh conversation, not a fresh project.
What a commit is, and what it is not
The assistant commits. That is real: the commit is in the repository on the volume, git log shows it, and you can go back to it. It is your undo button and it is the reason the reviewer can read a diff.
The assistant does not push. Not “is discouraged from” — cannot: your forge token is attached to the buttons in the Source control panel and to nothing else, so a git push run as a command has no credential and fails to authenticate. Sending your code to somewhere permanent is a thing a person does, on purpose, having looked at what is going.
So a project with no remote can commit all week and still have nothing anywhere but this machine. The workspace header says Not published while that is the case, and the Source control panel says it in full.
The three ways a project starts
What you have after each one, and what to press:
| Started from | Has a remote? | To publish it |
|---|---|---|
| A clone URL | Yes. The clone sets origin, and the token is taken back out of it afterwards — the URL git keeps has no credential in it. | Nothing to publish. Push, in Source control. |
| A zip upload | No. The upload is committed as Studio Code: seeded project, and there is nowhere for it to go. | Publish to GitHub, then Push from then on. |
| Nothing (blank) | No. The workspace is git inited on first use, with main as the branch and one empty commit to hang the history off. | Publish to GitHub, then Push from then on. |
Once a project has a remote, all three are the same project: fetch, pull and push, and git clone it wherever you deploy from.
Publish to GitHub
In the Source control panel, on a project with no remote. It creates the repository with your saved GitHub token, points origin at it and pushes the branch you are on — in that order, so a failure leaves as little behind as possible.
It needs a token that can create repositories, which is more than pushing to one needs. A classic token needs the repo scope. A fine-grained token needs Administration: read and write to make the repository and Contents: read and write to push to it, with your account as the resource owner. The publish form checks for the token before it offers to create anything, and says this there.
The repository is private unless you say otherwise, and it is created under the account the token belongs to. Organisation repositories need an owner to choose between, which is not built yet — create the repository in the organisation yourself, paste its URL into Repository URL in project settings, and push.
Your token is stored encrypted, never shown again after you paste it, and reaches git through one command’s environment — so it is in no file in the workspace, in no process list, and in nothing the assistant can read. It is never written to .git/config.
Download the workspace
The route out that needs no forge, no token and no network beyond Studio itself: Download .zip, in the file panel’s header and in project settings. It runs zip inside the container, so it wakes one that has gone to sleep and the first one takes a moment.
.git is included, which is the point: unzip it, and git log shows every commit the assistant made. Push it anywhere you like from there. Without git history is the second button, for when you only wanted the files. node_modules, build output and the usual caches are left out of both.
There is a size cap, and a project that exceeds it is told which directories are the reason rather than just refused. If a genuinely large project cannot be zipped, publish it instead — a push has no such limit.
Getting it somewhere it runs
Studio Code does not deploy. Once the work is on a forge that is somebody else’s job and there are twenty good answers to it, all of which start with git clone.
The preview pane is not one of them. It is a look at a dev server inside the sandbox, on this machine, for you — not a URL to send anyone.
If you are not sure where your work is
- Look at the workspace header. Not published means there is no remote and nothing has left this machine.
- Open Source control. With a remote it shows Fetch, Pull and Push and names the host; without one it says so and offers the three ways out.
- Download the zip. It works in every state, including one where the forge, the token or the network is the problem, and it takes about a minute.