01The default branch is the release trigger
Whatever your repository calls it, main or master or something older, the branch GitHub treats as default is the one the pipeline watches. A push there deploys. That single rule is the whole deployment model, which is either the simplest thing you have read today or suspiciously simple, and the suspicion is reasonable: the rest of this page is about what the rule implies.
The mechanics of the push itself are on their own page, and the pillar page keeps the whole set in view. This one is about choosing what reaches that branch.
02How a change reaches production
Make the change
Ask your agent, or edit the files yourself. The pipeline does not know or care who typed.
Land it on the default branch
Directly, for small confident changes, or by merging a branch that had a life of its own first. Only the default branch publishes.
Push
The webhook sees the commit, the build validates, and the release goes live over HTTPS with its number in the history.
Look at the site
Click through the changed pages like a visitor would. If something is off, rollback restores the previous release while you work out why.
03Branch first, merge when it is right
Working on a branch
Push as often as you like; a branch deploys nothing. The live site keeps serving the last release from the default branch while a half-finished redesign sits in view of nobody. This is a staging arrangement without a staging server.
Merging to the default branch
The merge is one push, and it deploys like any other. If the merged result was wrong, rollback puts the previous release back while you read the diff. Your git history never learns about any of the drama.
04What never deploys
Other branches. Open pull requests, which are proposals until merged. Commits that exist only on your machine. Files outside the repository. And, honestly, per-branch preview URLs: this pipeline does not host a URL per branch, and the preview and production guide says what we do instead, and for whom that is a genuine gap.
The list is short because the rule is short. One branch is live; everything else is drafting.
05Branching and shipping questions
Which branch deploys?
The default branch of the repository, whatever it is named. Change the default in GitHub and the pipeline follows the setting.
What if my agent pushes straight to main?
Then main deploys; that is the arrangement. If you would rather review first, tell the agent to work on a branch and merge when you are satisfied.
Does rollback rewrite my git history?
No. Releases are the record kept by the host; commits are yours. After a rollback, fix forward with a normal push and the history reads like it happened.
Two pushes in quick succession?
Each push becomes its own release, and the last validated one is what the site serves, so stepping back a single release is always available.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.