If your team has a dev branch that's been alive for 3 months, a staging branch that's never caught up to main, and a release branch that's a merge disaster — you're doing trunk-based development wrong, or not at all. The pattern works. It's been proven at scale. The only reason teams abandon it is because they've never seen it done properly.
Trunk-based development means main is your source of truth. No dev branch. No staging branch. Features land on short-lived branches (1–3 days max), deployed to Netlify preview URLs for review, then merged straight to main. Main is always production-ready. You ship when you want, not when you've untangled three weeks of merge conflicts.
Why Long-Lived Branches Are Toxic
A dev branch feels safe. "We'll keep development separate, then merge to main when we're ready." In reality, a dev branch that lasts more than a few days becomes a pain silo. By day 5, main has moved on. Merging dev back is a conflict nightmare. By day 10, dev is stale enough that you question whether it's worth merging at all. By month 3, the dev branch is a graveyard of half-finished features and broken imports.
Long-lived branches also hide integration problems. A feature might pass tests on a dev branch, but on main it breaks three other things because main evolved while the branch was isolated. You don't find out until the merge, when it's too late to back out cleanly. That's exactly why merges feel dangerous — because they are, when branches diverge.
The real risk isn't short feature branches — it's long ones. Short branches mean you catch integration issues fast, merge frequently, and keep the codebase cohesive.
Trunk + Short-Lived Features
Create a branch for each feature or fix. Push to Netlify. Get a preview URL. Review the rendered output. Merge to main. Delete the branch. Repeat. A typical branch lives 1–3 days. The whole team stays on a near-current version of main.
Here's what the workflow looks like:
{`# Start a feature
git checkout -b feat/add-dark-mode
# Edit, commit, push
git push -u origin feat/add-dark-mode
# Netlify auto-deploys to https://feat-add-dark-mode--mysite.netlify.app
# You see the rendered page, verify it works, then:
git checkout main
git merge feat/add-dark-mode
git push
# Delete the branch
git branch -d feat/add-dark-mode
git push origin --delete feat/add-dark-mode`}That's it. No PR ceremony. No 10-day review cycle. If you're using Velocity X or a similar Netlify-driven site, the preview is live within seconds. You can share it with teammates or stakeholders, get feedback synchronously, and merge once everyone agrees. Main is updated in less than a minute.
Branch Previews as the Review Surface
The killer insight: Netlify branch previews replace code review for most visual work. Instead of reading a diff and guessing what the page looks like, you click a link and see it rendered. Mobile, desktop, dark mode — all live. You can't get that from looking at code. A rendering bug is invisible in a diff but obvious on the rendered page.
For Velocity X, this means you can add a new blog post, see the preview URL, scroll through it on mobile, check that internal links work — all before merging. If something's off, you ask for revisions. If it's right, you merge. No surprises.
That's why branch previews are load-bearing infrastructure for trunk-based dev. They make the short-branch model safe. You're not trusting that code reviews will catch everything — you're letting the deployed site speak for itself.
Feature Flags for Incomplete Work
What if a feature isn't finished but main needs to ship? That's where feature flags come in. Wrap incomplete code in a conditional. Merge to main. Main still ships. The incomplete feature just stays hidden behind the flag until it's ready.
{`if (enableNewDashboard) {
return On the branch preview, you enable the flag and test the new version. On production, it's off until you're confident. This decouples merging from shipping — a branch can be merged to main and deployed to production without shipping the feature yet. Small, frequent merges. Ship whenever you're ready.
Six FAQs
Won't merging broken code to main break production?
Only if you don't review the branch preview before merging. The preview is your gate. If the build is broken or the rendered output is wrong, you don't merge. Simple discipline. Everyone on the team knows: no merge without a preview sign-off.
What if two branches conflict?
You'll find out the moment you try to merge the first one, because main has moved on. Fix the conflict and re-push. The preview rebuilds. You verify it still works, then merge. Conflicts are caught early, not buried until a 3-way merge.
How do I handle hot-fixes if main is always deployed?
Main IS the hot-fix branch. If a bug hits production, you create a branch, fix it, preview it, and merge to main. Main rebuilds and deploys automatically. Total time: under 5 minutes. No separate release branch. No waiting for a staging environment. Netlify does it for you.
What if I need to revert a merge?
Use git revert to create a new commit that undoes the previous one. Push, preview, merge. On Netlify, you can also one-click rollback to an earlier commit. Either way, the bad code is out within seconds. No branching required.
What about CI/CD — don't I need a staging environment?
Branch previews ARE your staging environment. Every branch gets a built, deployed version. Staging is redundant if your preview deployment matches production exactly, which Netlify ensures. One less environment to manage.
How do I keep main clean if everyone's committing directly?
Enforce commit message conventions and lint rules in pre-commit hooks. Require branch previews to pass before merging (Netlify status checks). Use a merge-queue bot if you're paranoid. The discipline isn't that everyone codes perfectly — it's that merges are reviewed on the rendered output, not just the code.
The Bottom Line
Trunk-based development isn't a free pass to chaos. It's the opposite: discipline that forces you to integrate frequently, review correctly (on rendered pages, not in diffs), and ship safely. Main is shippable because you kept the branch short and verified the preview. You ship faster because you're not managing three long-lived branches. You sleep better because integrations are tested daily, not discovered on merge day.
If you're running Velocity X on Netlify, you already have the infrastructure. Commit to the trunk-based model, use branch previews as your review gate, and watch your ship speed multiply. See pricing for Velocity X templates, and check out our Netlify branch preview deep-dive for the full setup.