Skip to main content
Engineering9 min read

Git Workflows That Don't Make You Want to Quit

Trunk-based vs GitFlow vs GitHub Flow — I've used all three. Here's what actually works for solo developers and small teams, and why most Git workflows are over-complicated.

By Jason TeixeiraOctober 25, 2025
GitVersion ControlWorkflowDevOpsBest Practices
Share:
On this page

I've worked with GitFlow on larger projects. Feature branches, develop branches, release branches, hotfix branches. The branch graph looked like a subway map. Merging a feature required a PhD in conflict resolution.

Now I use trunk-based development. One branch. Ship from main. My deploy frequency went from weekly to daily.

Why Most Git Workflows Are Over-Complicated

GitFlow was designed for software that ships quarterly on physical media. If your deployment process involves burning a CD, you need release branches.

If you deploy by merging to main and Vercel/GitHub Actions handles the rest, you don't need 90% of GitFlow.

What I Actually Do

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Engineering

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild a1556e22026-06-19 03:29Z
// solo studio// no analytics resold// every commit human-reviewed