<p>Git Flow is dead. GitHub Flow is too simple for large teams. Trunk-based development sounds great in blog posts but terrifies anyone who’s had a bad deploy. After managing Git workflows across teams from 5 to 500 engineers, here’s what I’ve learned actually works.</p>
<h2>Why Git Flow failed</h2>
<p>Git Flow was designed for packaged software with release cycles. It has:</p>
<ul>
<li>A develop branch</li>
<li>Feature branches off develop</li>
<li>Release branches off develop</li>
<li>Hotfix branches off main</li>
<li>Main that represents production</li>
</ul>
<p>In theory, organized. In practice: merge hell. Teams with 20+ engineers had develop branches that diverged from main by hundreds of commits. Release branches became week-long integration nightmares. Hotfixes required cherry-picking across four branches.</p>
<p>The core problem: too many long-lived branches. Every long-lived branch is a delayed merge conflict waiting to happen.</p>
<h2>Why pure trunk-based fails in practice</h2>
<p>Trunk-based development says: everyone commits to main, deploy main continuously.</p>
<p>For a team of 5 senior engineers with excellent test coverage? Perfect. For a team of 50 with varying experience levels, external dependencies, and compliance requirements? Recipe for disaster.</p>
<p>The problems:</p>
<ul>
<li>Broken commits hit main directly and affect everyone</li>
<li>Feature flags for everything creates flag management overhead</li>
<li>Rolling back means reverting commits that other work depends on</li>
<li>Compliance reviews can’t happen on individual commits fast enough</li>
</ul>
<h2>What actually works: Short-lived branch + ship gates</h2>
<p>Here’s the workflow I’ve seen succeed at scale:</p>
<h3>1. Short-lived feature branches (max 2 days)</h3>
<p>Every change gets a branch. But the branch must merge within 48 hours. If a feature takes longer, break it into smaller increments behind a feature flag.</p>
<p>The 48-hour rule prevents divergence. A branch that’s 2 days old might have 3-4 conflicts. A branch that’s 2 weeks old might have 30.</p>
<h3>2. Required CI before merge</h3>
<p>Every branch must pass:</p>
<ul>
<li>Lint and type checks</li>
<li>Unit tests</li>
<li>Integration tests relevant to changed files</li>
<li>Security scanning</li>
<li>Build verification</li>
</ul>
<p>This runs in 5-10 minutes, not 45 minutes. If your CI takes longer, fix CI first — it’s blocking everything else.</p>
<h3>3. One approval, squash merge</h3>
<p>One reviewer. Not two, not three. One person who understands the area of code being changed. Squash merge so main has a clean, linear history where each commit is a complete, deployable change.</p>
<h3>4. Ship gates, not release branches</h3>
<p>Instead of release branches, use deployment gates:</p>
<pre><code><span class="hljs-selector-tag">main</span> → CI passes → staging auto-deploy → smoke tests → production deploy (manual gate)
</code></pre>
<p>The manual gate is a human saying “yes, deploy this.” It takes 30 seconds. It catches the things automation can’t — “we shouldn’t deploy during the Super Bowl” or “wait, the database migration needs to run first.”</p>
<h3>5. Revert-first culture</h3>
<p>If something breaks in production, the first action is always: revert the commit. Don’t debug in production. Don’t rush a fix. Revert, restore service, then debug at your leisure.</p>
<p>This only works with squash merges — each commit on main is atomic and independently revertable.</p>
<h2>The tooling that enables this</h2>
<ul>
<li><strong>CI in under 10 minutes</strong> — if it’s slower, teams skip it</li>
<li><strong>Automated staging deploys</strong> — every merge to main deploys to staging</li>
<li><strong>Feature flags</strong> — for changes that span more than 48 hours of work</li>
<li><strong>Automated rollback</strong> — one-click or automatic on error rate spike</li>
<li><strong>Linear history on main</strong> — squash merges, no merge commits</li>
</ul>
<h2>The uncomfortable truth</h2>
<p>Git workflow problems are usually people problems in disguise. Merge conflicts come from poor task decomposition. Long-lived branches come from unclear requirements. Failed deploys come from insufficient testing.</p>
<p>The best Git workflow is the one that forces good engineering habits: small changes, fast feedback, and the courage to revert.</p>
<p>What Git workflow does your team use? Have you found something better than what I’m describing?</p>


sirajju

An experienced engineer breaks down why Git Flow and pure trunk-based development both fail at scale, then proposes a practical hybrid: short-lived feature branches (max 48 hours), mandatory CI gates under 10 minutes, single-reviewer squash merges, deployment gates instead of release branches, and a revert-first culture. The approach prioritizes small atomic changes, fast feedback loops, and clean linear history on main to make rollbacks safe and reliable.

Git Workflows Are Broken — Here's What Actually Works at Scale

<p>The 48-hour branch lifetime rule changed everything for our team. We went from week-long integration sprints to continuous delivery almost overnight. The key was realizing that if a branch can’t merge in 48 hours, the problem is the task decomposition, not the Git workflow.</p>
