Git Workflows That Actually Work at Scale
GitFlow vs trunk-based development vs GitHub Flow. Real teams have tried all three. Here's which one scales, which one slows you down, and the branching strategy Netflix uses.
Sri Balaji
Founder · TheSimplifiedTech
GitFlow: powerful but often overkill
GitFlow defines two permanent branches (main and develop) and three types of temporary branches (feature, release, hotfix). It was designed for software with scheduled release cycles — mobile apps, versioned desktop software. For web applications that deploy continuously, GitFlow introduces ceremony without value. Merge conflicts become frequent. The develop branch diverges from main. Hotfixes require cherry-picks across branches. Teams slow down.
Watch out
If your team spends more time managing branches than shipping features, GitFlow is probably the wrong model for your release cadence.
Trunk-based development: what high-velocity teams actually do
Netflix, Google, Meta, and Spotify all use trunk-based development. Engineers commit directly to main (trunk) or use very short-lived feature branches (1–2 days max). Every commit to main triggers CI/CD. Feature flags control what users see — incomplete features ship but stay hidden behind a flag until ready. This approach requires: fast CI pipelines, comprehensive test coverage, feature flag infrastructure, and a team culture comfortable with frequent small changes.
# Short-lived branch — merged in < 2 days
git checkout -b feat/payment-retry
# ... small, focused changes ...
git push origin feat/payment-retry
# Open PR → review → merge to main → auto-deployGitHub Flow: the pragmatic middle ground
GitHub Flow is simpler than GitFlow and safer than pure trunk-based development. One permanent branch (main). Feature branches off main. PR required to merge. Deploy from main. No develop branch, no release branches, no hotfix branches. This works well for teams of 5–50 engineers shipping multiple times per week. It's the model used by most SaaS startups and the one I recommend to most teams I mentor.
What Netflix actually does
Netflix uses trunk-based development with a sophisticated feature flag system called Archaius. Engineers merge to main multiple times per day. The CI pipeline runs in under 10 minutes. Deployment is automatic. Rollback is one command. The entire system is built around the assumption that you will deploy broken code — the goal is to detect and revert it fast, not to prevent it from merging. This is only possible with comprehensive observability and a mature on-call culture.
How to choose
Team < 5 engineers shipping continuously → GitHub Flow. Team 5–50, multiple environments → GitHub Flow with environment branches. Large team, multiple release schedules → GitFlow. High-velocity team with strong CI/CD and feature flags → trunk-based development. The Git Basics lab on this platform covers branching, rebasing, cherry-pick, and stash — the mechanics you need regardless of which flow you adopt.
Pro tip
Whichever model you choose, the most important rule: keep branches short-lived. Long-lived branches = merge conflicts = slow teams = unhappy engineers.
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths — with real terminal labs, production scenarios, and structured lessons.