GitFlow was the dominant branching strategy for most of the 2010s. Feature branches, develop branches, release branches, hotfix branches — it provided structure for teams that needed it. But in 2026, most teams I work with have moved on. Here’s what replaced it and why.

Why GitFlow Lost Favour

GitFlow was designed for a specific context: software with discrete releases, long release cycles, and teams that needed to maintain multiple versions simultaneously. Think desktop applications or on-premise software with version numbers.

Modern web applications deploy continuously. There’s no “release 2.3” — there’s just the latest commit on main, deployed automatically. In this context, GitFlow’s ceremony (separate develop and main branches, release branches, version tags) adds overhead without providing value.

The other issue is long-lived feature branches. GitFlow encourages branches that live for days or weeks, which leads to painful merge conflicts and “integration hell” when multiple features converge.

Trunk-Based Development

Trunk-based development is the most radical departure from GitFlow: everyone commits directly to main (or via very short-lived branches that last hours, not days).

The rules are simple:

1. Main is always deployable
2. Branches live for less than a day
3. Feature flags hide incomplete work
4. Every commit runs the full test suite
5. Broken main is the highest priority fix

This sounds scary if you’re used to long-lived branches and code review before merge. It requires a few prerequisites:

A strong test suite. If you can’t trust your tests to catch regressions, you can’t trust direct commits to main. Invest in testing before adopting trunk-based development.

Feature flags. Incomplete features ship behind flags that are off by default. Users don’t see work-in-progress code, but it’s integrated into the codebase continuously, preventing merge conflicts.

Fast CI. Your test suite needs to run in under 10 minutes. If CI takes 30 minutes, developers either skip it or batch up changes, defeating the purpose.

Google, Meta, and Microsoft use trunk-based development at massive scale. If it works for codebases with millions of lines of code, it works for your 50,000-line application.

GitHub Flow

GitHub Flow is the middle ground that most small-to-medium teams settle on. It’s simpler than GitFlow but more structured than pure trunk-based development:

1. Main is always deployable
2. Create a branch from main for each change
3. Open a pull request when the branch is ready
4. Review, discuss, and approve the PR
5. Merge to main
6. Deploy immediately (or automatically)

The key difference from GitFlow: there’s no develop branch, no release branches, no hotfix branches. Just main and short-lived feature branches.

The critical word is “short-lived.” A GitHub Flow branch should live for one to three days at most. If your PR is open for a week, it’s too large. Split it into smaller changes.

Ship/Show/Ask

Ship/Show/Ask is a newer framework that I find particularly pragmatic:

Ship: For changes you’re confident about — small bug fixes, documentation updates, config changes — commit directly to main. No PR needed.

Show: For changes that benefit from visibility but don’t need blocking review — refactors, test additions, minor features — open a PR, merge immediately, and let teammates review after the fact.

Ask: For changes where you genuinely need input — architectural decisions, complex features, security-sensitive code — open a PR and wait for review before merging.

This framework acknowledges that not all changes carry the same risk or need the same level of review. A typo fix doesn’t need a formal review process. An authentication change does.

The challenge is calibration. Team members need to agree on what falls into each category, and that agreement evolves over time. New team members start in “Ask” mode for everything and gradually earn “Ship” trust as they learn the codebase.

What I Recommend

For most teams, start with GitHub Flow. It’s well-documented, supported by every code hosting platform, and provides enough structure to prevent chaos without the overhead of GitFlow.

If your team has strong testing practices and wants to move faster, evolve toward trunk-based development. Add feature flags, tighten your CI pipeline, and gradually reduce branch lifetimes.

If your team has high trust and varied experience levels, Ship/Show/Ask provides the flexibility to let experienced developers move fast while maintaining guardrails for complex changes.

The One Rule That Matters

Regardless of which workflow you choose, one principle matters more than all others: keep branches short-lived. A branch that exists for a week is a merge conflict waiting to happen. A branch that exists for an hour integrates smoothly.

Long-lived branches are the root cause of most Git workflow pain. Whatever strategy you adopt, optimise for merging early and often. Your codebase and your team will be better for it.