Build apps
Source Control
Review, stage and commit changes, go back to any agent turn, see your app's history, and push to GitHub or another git host.
Review, stage and commit changes, go back to any agent turn, see your app's history, and push to GitHub or another git host.
Every project is a git repository. The Source Control tab shows what changed and lets you stage, commit, push and go back, without the Shell. It works like the Source Control view in VS Code.
Open it from the + button in the tab bar, or Tools → Source Control. Its address is ?tab=source-control; older links to ?tool=git open it too.
From the top:
Below that are the changes, in up to three lists:
| List | What’s in it |
|---|---|
| Merge changes | Files with conflicts. Fix the conflict markers (or ask the agent to), then mark the file resolved. |
| Staged changes | What the next commit will contain. |
| Changes | Everything else you or the agent changed. |
Each file shows its icon, name and folder, the lines added and removed, and its state: M modified, A added, D deleted, R renamed, U new (untracked), ! conflicted. Hover a file for its actions: open the file, discard its changes, and stage or unstage it. Press ↑/↓ to move between files.
node_modules, vendor, .cache and .env files (except .env.example) never show up and are never committed.
While the agent is working, committing, discarding, switching branches and restoring wait until it finishes. Source Control works while the sandbox is running.
Click a file to see its diff on the right: old and new line numbers, the code colored by its language, and the words that changed within an edited line highlighted. A new file is all green; a new folder lists its files.
On a narrow pane, the list and the diff take turns: click a file to open its diff and Back to return to the list.
Staging works like git add: what you stage stays staged, in the Shell too, until you commit or unstage it. git diff --cached in the Shell shows the same thing as Staged changes.
You can stage parts and lines of edited text files. A new file is staged whole.
Discard throws away unstaged changes only, after you confirm. What you’ve staged stays. Edited files go back to their staged or last committed state, new files are deleted, and ignored files like node_modules and .env are kept. The files as they were are saved in the Timeline first, so you can get discarded work back.
The Commit & push button next to Share shows how many files have changed. Click it to open Source Control with the cursor in the message box. With nothing to commit but commits not yet pushed, it pushes instead. Without a connected repository the button says Commit.
Its arrow opens Commit…, Push (or Connect a repository… when there’s none), Undo last commit, Combine N commits and Create PR.
The Commit after each agent turn switch is under Repository in Source Control.
It’s on for new projects. Connecting a repository, or starting a project from one, turns it off: that history is yours to write. Turn it back on any time.
With it off:
Every agent turn is saved as a private checkpoint, whether or not anything is committed. Edits you make outside the agent, in the Shell or the Files panel, are saved as their own Changes outside the agent checkpoint before the agent’s next turn and before each backup.
The Timeline lists them newest first, each with an icon (agent turn, changes outside the agent, restore, or applied task), when it happened, and the files and lines it changed. Click one to see its files and their diffs.
A restore changes your files but commits nothing, and what you’ve staged stays staged. Your current files are saved as a checkpoint first, so you can undo a restore by restoring that one.
Checkpoints are kept out of your branches and are never pushed to your repository.
History lists the project’s commits, newest first, with who made each one (the agent’s are marked Agent), how long ago, and its short id.
Search it with the box next to History: it looks through every commit’s message and author (type agent for the agent’s turns), or finds a commit by its id. Show more lists older commits, 50 at a time.
Click a commit to see its details on the right: its full message, author and email, the exact date and time, its full id (with a copy button), and the files it changed with their diffs.
Open the ⋮ menu on the newest commit and choose Undo this commit (or Undo last commit in the … menu). After you confirm, the commit is gone and its changes are back as uncommitted, so you can change them or commit them differently. Your files don’t change.
Only a commit that isn’t pushed yet can be undone, so your repository never has to be overwritten. For a pushed commit, restore the version before it instead. The very first commit and merges can’t be undone.
Open the ⋮ menu on a commit and choose Restore this version. Every file goes back to how it was at that commit, saved as a new commit, and the app restarts. To undo it, restore the version before it the same way. Uncommitted changes aren’t committed first: they’re saved in the Timeline.
Combine N commits appears when more than one commit is waiting to be pushed. It turns them into one commit with a message your project’s AI writes from them, listing the original messages underneath; edit it before combining. Only commits that aren’t pushed yet are combined, so pushing never has to overwrite your repository, and your files don’t change. If something is staged, commit or unstage it first; unstaged changes are left alone.
On a branch other than main or master that’s pushed to a GitHub repository, Create PR opens a dialog. Pick the branch it goes into (main or master to start with), and your project’s AI writes a title and description from the branch’s commits and changes. Edit them, then click Open on GitHub: GitHub’s new pull request page opens with both filled in, ready to create. Without an AI, the title is the branch’s only commit message (or the branch name) and the description lists its commits.
When Create PR isn’t available, the menu says why: Commit on a new branch first, Push the branch first, or Needs a GitHub repository.
The Repository section holds the Commit after each agent turn switch, the connected remote repository (or Connect to GitHub), and when the project was last backed up.
OneDrop backs up the project’s history and Timeline outside its sandbox. If the sandbox is ever lost, your commits come back, and work that wasn’t committed comes back as uncommitted changes.
The branch menu at the top of the left column shows the current branch. Pick another to switch to it, or choose New branch… to start one from the current commit. The app restarts on the new branch.
Connect a remote repository to push your commits to it and pull commits others made.
If your OneDrop has a GitHub App set up, click Connect to GitHub. A dialog walks you through it.
The first time, click Continue to GitHub. On GitHub, pick your account or an organization, choose all repositories or only the ones OneDrop may use, and approve. GitHub brings you back with the dialog open. If you end up back on the project without GitHub bringing you, open Source Control: the dialog asks Finished installing on GitHub? Click Continue to pick up the installation.
Then pick an owner (your account or an organization) at the top of the dialog, and either:
The name is suggested from your project, and OneDrop checks as you type that it’s free. Choose Private or Public.
The dialog opens on New repository when your project has commits, and on Existing repository when it doesn’t. Add account or organization installs the app somewhere else.
You only see repositories that both you and the app can reach. No token is stored for the project: OneDrop gets a short-lived one from GitHub each time it pushes or pulls. A pull, and bringing the repository in when a project starts from it, is downloaded by the project’s sandbox with a token that can only read that repository and expires within an hour, so even a large repository (hundreds of MB of history) comes in. Pushes always go through OneDrop’s server. If your GitHub sign-in expires, the dialog asks you to reconnect.
Without the GitHub App, or for another git host (Other git host), connect with an access token:
repo scope).Push sends the current branch to the remote. Pull brings in commits the remote has that the project doesn’t. Both run in the background; the card shows Pushing… or Pulling…, then how many commits there are to push or pull.
The token is stored encrypted by OneDrop and never shown again. It never goes into the sandbox: pushes and pulls run on OneDrop’s server, which carries commits in and out of the sandbox. Remotes must use HTTPS, and on the public internet unless your admin allows private networks (see configuration).
Projects can download the private GitHub packages you can see, like a codespace does: Docker images on ghcr.io and npm packages on npm.pkg.github.com. No personal access token needed.
Every sandbox of a project you own, task copies too, then has your GitHub token as GITHUB_TOKEN, in the Shell, the app and the agent. Docker is signed in to ghcr.io with it, and npm to npm.pkg.github.com, so docker compose up, docker pull ghcr.io/… and npm install just work. Tools → Secrets shows it under From (your name)’s GitHub.
@scope package on npmjs.org, point the scope at GitHub once: npm config set @scope:registry https://npm.pkg.github.com. The agent does this when it needs to.GITHUB_TOKEN wins over yours, so an admin can share one token instead.Only package reading (read:packages) is asked for, not access to your repositories. The token never goes into the project’s files or your home folder, so it doesn’t end up in commits, hosted apps, snapshots or remixes. Your organization’s owners and admins, who can open your projects’ Shell, could read it there. Your admin needs a GitHub OAuth app for this (see social login).