Branches
How a branch name decides which environment a push deploys to, and which URL it gets.
Gigadrive Network tracks every branch it has seen a deployment for and assigns each one to an environment. That assignment is what decides whether a push replaces production or only updates a preview URL.
What a push produces
With a connected repository and automatic deployments on, a push to any branch starts a build. Three kinds of push do not:
- Deleting a branch.
- Pushing a tag. Only refs under
refs/heads/deploy. - Pushing a commit that already has a deployment on the same branch and repository, unless that deployment failed.
Pushing again while a build for the same branch is still running cancels the older build. It ends as FAILED, and only the newer commit publishes, whatever order the two pushes arrive in.
To stop pushes from deploying at all, turn off Automatic deployments under Settings, Git. The switch covers the whole application; there is no per-branch exclusion.
Branch to environment
A new application has two environments: Production, which claims the branches main and master, and Preview, which takes everything else. When a deployment carries a branch, that branch resolves to an environment like this:
- The first environment of type production or custom whose branch patterns match the branch name. Environments are checked in the order they were created, so Production is always considered before any environment you added.
- Otherwise the Preview environment.
A pattern is either an exact branch name or a wildcard. * stands for any sequence of characters and the whole name must match, so release/* matches release/2026-01 and not hotfix/release/2026-01. A bare * is rejected, because Preview already is the fallback.
Edit patterns under Settings, Environments, then Edit branch routing. Saving re-evaluates every branch the application already knows about, so a staging branch moves to its new environment at once and its next push deploys there.
Branch URLs
Each branch keeps one URL that always points at its most recent deployment:
<name>-git-<branch>.gigadrive.appThe branch part is slugified, so feature/login becomes feature-login. Two branches whose names slugify to the same string get a short suffix derived from the branch, which keeps them apart. Renaming your production hostname label migrates every branch URL to the new label in the same operation, and frees the old ones.
The branch URL moves on every successful deployment of that branch, whatever environment the branch belongs to. Only a deployment in the Production environment also moves the bare <name>.gigadrive.app URL. Domains covers the hostname model in full.
Deploying one branch on demand
In the console, Deploy on an application opens a dialog that takes either a branch name or a commit SHA of at least 7 characters. A branch deploys its latest commit; a SHA deploys exactly that commit.
import { GigadriveClient } from '@gigadrive/sdk';
const client = new GigadriveClient();
// Latest commit on the branch.
const latest = await client.deployments.create({
applicationId: '0197b2f1-2f4a-7a0b-8a2d-222222222222',
gitSource: { ref: 'release/2026-01' },
});
// Or pin the exact commit.
const pinned = await client.deployments.create({
applicationId: '0197b2f1-2f4a-7a0b-8a2d-222222222222',
gitSource: { ref: 'release/2026-01', sha: '4f0c1d9a2b3e5f6708192a3b4c5d6e7f80912a3b' },
});
console.log(latest.id, pinned.id);The build is queued straight away when you pass gitSource. Creating a deployment needs the network:deployments:trigger scope, and tokens issued to a deployment or a Function cannot create one at all.
The gigadrive CLI has no flag for deploying a ref. gigadrive deploy uploads your working directory instead, which is a different thing: it does not carry a branch and so lands in Preview.
Seeing what a branch has deployed
Branches appear in three places in the console: the application's Branches page, an environment's Branches page, and the branch filter on any deployment list. Each row carries the branch's latest deployment status, its commit, and the author. Branches you have never deployed do not appear, because the record is created by the first deployment that carries the ref.
