Version control

How your code is kept

Every deploy, edit, ship and push is a commit in the project's own repository on Yeeted. Nothing trims or rewrites that history. A project's stored source has a size limit set by your plan: over it, new writes are refused and nothing is deleted.

Every read takes a ref: main (the default), prod, a branch name, a version from versions_list such as v12, a deployed tag, a checkpoint name, or a commit hash (7 or more characters). Every reply names the ref it used and the commit it resolved to, so follow-up reads and edits pin to that commit.

Read and search over MCP

Tools shaped like the ones an agent already uses locally:

Edit, branch and ship

• source_edit saves a batch of edits (replace text, create, delete, rename) as one commit, up to 50 edits. Each edit names the blob hash the file was read at; if the file changed since, nothing is written and the reply is stale_read with the current content.
• Without a branch the commit goes to main, merged three-way with any newer commits, or refused as merge_conflict with the conflicting lines. With a branch the work stays off main until you ship it.
• deploy(branch=...) runs a branch as its own development version with its own preview address, next to the project's.
• ship(branch) merges the branch into main as a merge commit and deploys development. If both changed the same lines, nothing is merged and the branch stays intact: resolve with source_edit(branch, merge_main=true), then ship again.
• revert(from, to) undoes the changes between two revisions on main as one new commit. Nothing is deleted from history.
• Whole-project uploads still work: source_upload takes an archive, and deploy(files, base, partial=true) sends only the files you changed on top of base.

The owner, admins and developers may change the code; a read_only member reads it. See Who can do what.

Several agents at once

• Claims. source_claim(paths, note) tells other agents you are reworking some files, for example src/auth/. A claim never blocks anyone: it shows up in source_status, in source_edit replies on those paths and in the change feed. It lasts 30 minutes by default (at most 4 hours), your commits on the same branch renew it, and it ends when that branch ships, when you call source_release, or when it expires. The owner or an admin can clear someone else's claim.
• The change feed. source_events long-polls like build_logs: commits to main, new branches, pushes, ships, merge conflicts, promotions, rollbacks and claims, oldest first. Start with after=0 for the last 30 days.
• Tasks. A merge conflict nobody was there to resolve, such as a hotfix that could not merge into main, becomes a task in source_status; source_task_done closes it.

Attribution

Every commit Yeeted makes records who made it, in two kinds kept apart. The person and the credential are verified by Yeeted from the connection. The agent, model and thread are what the agent reported about itself, through the provider, model and thread fields of the write tools. They are written into the commit and as git notes under refs/notes/yeeted-attribution. A pushed commit keeps its own hash, and the pushing account and credential are added as a note. source_log, source_show and source_blame show both kinds and mark the agent's as self-reported; source_log can filter by person, agent or thread.

Production: hotfix and rollback

• Hotfix. hotfix(branch) starts a branch from prod, exactly what production runs, without what main has gained since. Edit it, preview it with deploy(branch=...), then ship(branch, to="production") ships the tested preview and Yeeted merges the fix into main. If that merge conflicts, main is left alone and a task opens; a promotion that would undo the hotfix is refused. A hotfix may not change the database schema (migrations, ORM model and schema files, any .sql file). Hotfixes are for the owner and admins.
• Rollback. rollback(to=v12, service_type="production") swaps the running production image and points prod at v12's commit; no commit is deleted. Without service_type a rollback is for development and leaves prod alone. main still has the rolled-back changes: the reply offers revert to undo them, and promoting main before that warns.

Clone with git

Ask your agent for source_git_token(project_id). It mints a token valid for 1 hour, for that one project, and returns the exact commands:

git -c http.extraHeader="Authorization: Bearer <token>" \
  clone --branch main https://git.yeeted.ai/<project>.git

• The token goes in an http.extraHeader for that one command. It is never in the URL or in .git/config, so mint a new one for the next fetch once it expires.
• Treat it like a password: keep it out of files, commits and logs. It stops working when you lose access to the project.
• A clone has every branch and the deployed tags. To see who made each change, also fetch the notes: git fetch origin refs/notes/yeeted-attribution:refs/notes/yeeted-attribution (with the same header). Git 2.26 or newer is needed.

Push with git

source_git_token(project_id, access="write") mints a token that can also push. The owner, an admin or a developer of the project can get one, and revoke=true ends every write token you hold on the project.

git -c http.extraHeader="Authorization: Bearer <token>" push origin my-branch

• A version per push. With a token from a connection that holds the deploy permission, each pushed branch registers a development version at the pushed commit, built on the first visit to its preview address (or now, with deploy(branch=...)), and a push to main also deploys development unless yeeted.yaml sets git: { deploy_main_on_push: false }. Without the deploy permission a push only stores the code; deploy(branch=...) or deploy(git_hash=...) deploys it. The push output (remote: lines) says what was registered or deployed.
• No forced history. A forced (non-fast-forward) update of any branch or tag is refused; main, prod and tags cannot be deleted; a tag never moves; prod is never pushed (it moves when a version is promoted); a deleted branch's commits are kept. A refused push changes nothing: fetch, merge, and push again.
• Settings wait. A push never applies the project-wide settings in yeeted.yaml (waf, depends_on, repo, domains). When a push to main deploys, its output lists the settings it held back; the owner or an admin applies them with deploy(git_hash, apply_settings=true).
• The rules of the MCP tools apply to a push too: a hotfix branch needs the owner or an admin and refuses schema changes, submodules are refused, and the plan's size limits apply.

Connected repositories

If your code lives in your own repository, connect it with project_repo, over https on github.com, gitlab.com, bitbucket.org or codeberg.org; Yeeted checks that the address answers as a git repository before saving it. Push-to-deploy gives you a webhook for your provider, so every push to the branch deploys, and an optional mirror pushes every Yeeted deploy back to your repository. While a project is connected its code lives there: source_edit, ship, hotfix and revert are refused, and so is a push to git.yeeted.ai. Edit in your repository and push there. A push that rewrites your branch's history is not deployed until you run project_repo again with accept_rewrite=true; see Your code and data.