I presented this talk at VSLive Las Vegas 2026. Here's the deck and some notes on what it covers.
The Core Idea
A branch is an integration credit card. Short-lived branches are a small balance you pay off quickly. Long-lived branches are compounding interest. Until it's merged, it's not done.
Most teams I walk into have 47 open branches, some of them three months old, a "develop" branch nobody can explain, and main broke twice last week. They'll tell you they follow GitHub Flow. They do not follow GitHub Flow.
This talk isn't really about Git commands. It's about why we branch, and when branching is a helpful practice versus a sign of deeper team problems — fear-based development, no release strategy, unclear ownership. Before you redesign your branching strategy, ask what problem you're actually solving.
What We Cover
The first section walks through what branches actually are (a pointer to a commit, not a container for files), the major strategies everyone talks about (GitFlow, GitHub Flow, trunk-based development), and the gap between what teams say they do and what they actually do.
The middle section is where it gets practical. I recommend a sprint branch model for most teams — main is truth, you create a sprint/iteration branch, feature branches merge to the sprint branch, and the sprint branch merges to main. It handles hotfixes cleanly and scales to multiple teams without the merge disaster that comes from long-lived environment branches.
Which brings us to the cautionary tale: environment-based branching. This is the "IT'S NOT FINE" story. If you have long-lived branches for QA, staging, and production, you're resolving merge conflicts in your production branch — which means the code you're deploying is NOT what QA tested. You're betting everything on that merge going perfectly. It's not fine.
The back half covers build once/deploy many, feature flags (and their trade-offs), small PRs, PR anti-patterns (the rubber stamp, the gatekeeper, the perfectionist, the ghost), and encoding your strategy in branch protection rules so it's enforced, not just documented.
The Playbook
The punchline fits on one slide: don't branch unless you have a really good reason. A branch is a credit card and you WILL pay. Until it's merged, it's not done. Branch problems are usually people problems. And if you can't explain your strategy in two sentences, it's probably not great.
Download the Slides
If you want to go deeper, I have a full YouTube series on Branches That Don't Suck that covers each of these topics in detail.
—Ben
