Code Should Enter a Host Through Git, Not as an Upload

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

Code can reach a host as an uploaded archive or as a Git commit. Only a commit keeps four facts attached to every deploy: who made the change, which revision it is, what differs from the one before, and a previous version to return to. An archive loses all four. A commit can come from a push in your shell or from an agent in a browser chat that hands the files over.

This matters more now that an agent writes most of the code. The tempting shortcut is to let the chat window deploy whatever it holds. The shortcut is fine as long as it ends in a commit in a repository you can read, not in files dropped onto a server.

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 chat with no shell can still commit

An agent in a browser chat has no git, but it can pass the files it wrote to a host that commits them into a repository. The commit is the same record a push makes: an author, a revision, a diff and a predecessor. What changes is where the review happens. The diff never appeared on your machine, so somebody reads what the agent wrote in the repository's history, before the build.

Two limits keep that door narrow. The host writes only the files the agent passed, never code of its own, and it writes only into a repository it hosts for you. Your GitHub account stays read-only to it. An agent in a shell pushes with a credential you hold and can revoke, and connecting an existing GitHub repository to an agent follows the same boundary. Either way, an MCP deployment platform builds a named branch and nothing else.

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 a repository you own; 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, whether the code was pushed or committed from a chat. 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 a 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? Yes, if the host accepts files as a commit. The assistant writes the code in the conversation and hands the files to the host, which commits them into a repository and builds that commit. On aidrop.it this goes to the Team's own Git service; an agent with a shell pushes there or to a connected GitHub repository instead, and there is no archive upload either way.

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 a repository you own, 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.