Code Should Enter a Host Through Git and Nowhere Else

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

There are three ways code reaches a host: you upload an archive, the platform writes and commits on your behalf, or you push from a shell you control. Only the third keeps four facts attached to every deploy: who made the change, which revision it is, what differs from the one before, and a credential that stays in your hands. The other two lose at least one of those, and usually all four.

This matters more now that an agent writes most of the code, because the tempting shortcut is to let the chat window deploy. A chat window that cannot run git is a reader, not a writer. That is a boundary worth keeping, not a limitation to route around.

An uploaded archive has no history

A zip is a snapshot with nothing attached. It has no author, no revision and no diff, so the two questions a bad deploy raises first, "what changed" and "who changed it", have no answer except "whatever was uploaded last". A rollback needs a second copy that somebody remembered to keep. Nothing connects the running thing to the code anybody is looking at.

Uploads also invite the state that never gets committed: a config edited in place, a dependency dropped into the folder, the fix applied on the server. Each one works until the next upload erases it, and none of it is anywhere the next maintainer will look.

A platform that commits for you holds a write path a prompt can reach

If a chat client can say "deploy this" and the platform writes files and commits them, then the platform holds a credential to your repository and a prompt can trigger it. The prompt may be one you typed. It may equally be text an agent read in a page or a ticket. Either way the diff never appeared on your machine, so the step where somebody reads what the agent wrote is skipped by construction.

The split that keeps the review is simple. The agent writes on your machine, in a shell. You, or the agent in that shell, push with a credential you hold and can revoke. The host reads the branch it was told to build. A chat-only client, with no shell, can read the record and operate a build of what is already pushed; it cannot put code anywhere, and it should not be able to.

A push is a statement

A push says: this revision, on this branch, by this author, on top of that one. Every deploy then has a commit to name, and every commit has a diff to read and a predecessor to return to. The host needs no write access to any of it; it needs to receive pushes, or to read a repository somebody granted it.

Two consequences are worth writing into the team's rules. Only the tracked branch builds, so a push to any other branch deploys nothing, which is what makes a branch a safe place to work. The branch that builds is a service setting, not whatever branch somebody pushed last. And the repository outlives the deployable: one repository can back two running things, and deleting one of them should never touch the code.

Three questions every deploy should answer

Run these against any host. Take the commit the host reports as running, and keep the previous one from the last deploy record. If any question has no answer, code reached the host through another door, and that door is where the next surprise lives.

# 1. Which revision is live, and who made it?
git show --no-patch --format='%h  %an  %ad  %s' <deployed-sha>

# 2. What changed since the previous deploy?
git diff --stat <previous-deployed-sha> <deployed-sha>

# 3. Is anything running that is not in the repository?
git status --porcelain                     # on the machine that pushed: must print nothing
git branch -r --contains <deployed-sha>    # must name the branch the host builds

Keep the two commit ids with each deploy note and the commands become a habit rather than a search. They are also the fastest honest answer to "is production the same as main", which is the question every takeover starts with.

FAQ

Can I deploy without git? On some hosts, by uploading files or an archive. What you give up is the record: no author, no revision, no diff and no predecessor to return to. If a host offers both, push; the upload path is the one you will regret on the day something breaks.

Can ChatGPT or another chat assistant deploy my app? It can operate a deploy of code that is already in a repository, but it has no shell and no git, so it cannot put code there. On aidrop.it, code enters from a shell with git push, to the Team's own Git service or a connected GitHub repository; there is no archive upload, nothing ever commits on your behalf, and a chat-only client reads the record and builds what is already pushed.

Should my coding agent have push access? The agent running in your shell pushes with a credential you hold: scoped to one repository, and revocable at its issuer, the same way any access you give an agent should be. The platform behind the address never needs write access to your code, only the ability to read the branch it builds.

Why did my push not deploy? Usually because it went to a branch the host is not tracking. Only one branch builds; a push anywhere else is recorded and ignored. Check which branch the host follows before assuming the build failed.