The Branch That Builds Is a Setting

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

You pushed a fix, refreshed the application, and saw the old behaviour. The push succeeded. CI may even be green. The missing fact is which branch the service follows, because a host builds one named branch and ignores the rest.

A push changes a repository; it does not identify a release. The deploy record must say which branch it tracks and which commit from that branch it built. Without both, "the latest code" can mean the head on your laptop, the default branch on GitHub, or the revision still running in production.

The repository default is only the first answer

When a service first connects to a repository, the host records that repository's default branch as its first tracked branch. It could be main, master, or a release branch chosen years ago. Renaming the default later does not guarantee that every connected service follows the new name.

A monorepo makes the setting more visible. The API can follow main while a customer demo follows demo, even though both build from the same repository. The code source is shared; the release line is not. This is one reason git should be the only door code uses to reach a host: a commit and branch give the running revision a name you can inspect.

A feature-branch push should deploy nothing

Ignoring an untracked branch is a safety property. It lets an agent push review work without replacing the public application. The webhook may arrive and the provider may report success, but the host should compare the pushed ref with the service's tracked branch before it queues work.

This creates a clean separation: pushing records code; building releases the head of one branch. If you want to release the feature branch, change the tracked branch on purpose or merge it into the one already followed. A platform that deploys the branch changed last has turned repository activity into production control.

The same rule applies to manual builds. A build without a branch argument should take the recorded branch's head. A build with a new branch should verify that branch exists, record the change, and use its current head. A typo must fail before anything about the service changes.

Compare three commits before debugging the application

Most "my push did not deploy" investigations start in the logs. Start with commit ids instead. You need the local head you intended to release, the remote head of the tracked branch, and the commit the host reports as built or running.

If local and remote differ, the push did not carry the commit you thought. If remote and built differ, no build of that head has completed. If built and running differ, the last build failed or somebody rolled back. The next agent session should read that live state before it touches the repository.

A four-command branch check

Run this before changing code to fix a deploy that never contained your change. Replace the placeholders with the remote and branch from the host's own service record.

git fetch <remote>

# 1. Commit in the working tree
git rev-parse HEAD

# 2. Commit at the head of the branch the host tracks
git rev-parse <remote>/<tracked-branch>

# 3. Commits on local HEAD that the tracked branch does not contain
git log --oneline <remote>/<tracked-branch>..HEAD

# 4. Prove the host's reported commit belongs to the tracked branch
git branch -r --contains <host-reported-sha>

Record the comparison with the incident:

TRACKED BRANCH CHECK
service:
tracked remote / branch:
intended commit:
remote branch head:
last built commit:
running commit:
result: push missing | build pending/failed | rollback active | all match
next action:

FAQ

Why did my git push not deploy? The push may have gone to a branch the service does not track. Read the tracked branch from the host, fetch the remote, and compare its head with your intended commit before reading build logs.

Should a feature-branch push deploy? Only when each branch has an explicit preview environment. A production service should follow one named branch. Ignoring other branches lets people and agents push work for review without changing the public application.

How do I change the branch a service builds on aidrop.it? Pass branch to service_build. aidrop.it first checks that the branch exists, records it as the one that service follows, and builds its head. Later builds keep that branch until another call changes it, and service_get reports the recorded branch and commit.

Is the default branch always main? No. Imported repositories keep the default branch reported by their provider, which may be master, trunk, or another name. A repository created by a host may start on main, but the service record remains the authority for what builds.