Git Branching Strategies 2026: Trunk-Based vs GitFlow vs GitHub Flow

Every few months someone asks me which Git branching strategy their team should use, and the honest answer has barely changed in a decade: merge small changes to one main branch, often, behind tests and flags. What has changed in 2026 is the plumbing around that answer. GitHub shipped native stacked pull requests, merge queues are now table stakes on the big forges, and a growing share of pull requests are written by agents that never get tired of opening them. This post compares trunk-based development, GitFlow and GitHub flow, explains what the DORA research actually says about branching, and covers the tools that make a trunk workable when the PR volume goes up.

What are the main Git branching strategies in 2026?

There are really three families, and most "custom" strategies are one of them with extra rules bolted on.

GitFlow is Vincent Driessen's 2010 model: a long-lived develop branch beside main, feature branches off develop, release branches for stabilisation, and hotfix branches off main. It was designed for software shipped as numbered versions.

GitHub flow is the six-step loop in GitHub's own docs: create a branch, make changes, open a pull request, address review, merge to the default branch, delete the branch. There is one long-lived branch and the PR is the unit of work.

Trunk-based development goes one step further. Everyone integrates into the trunk at least daily, branches are short-lived and belong to one workstation (or pair), and incomplete work hides behind flags rather than on a branch. The trunkbaseddevelopment.com reference site describes small teams committing straight to trunk and larger ones using short-lived feature branches that exist only for review and CI, with release branches cut from trunk just in time if you need them at all.

In practice GitHub flow with branches that live for hours rather than weeks is trunk-based development. The difference between them is discipline about branch lifetime, not tooling.

Strategy	Long-lived branches	Integration cadence	Fits best	Source
GitFlow	main + develop, plus release and hotfix branches	at release time	versioned software, several supported versions	nvie.com
GitHub flow	default branch only	per merged PR	web apps and services deployed continuously	GitHub Docs
Trunk-based	trunk only (release branches optional, short-lived)	at least once a day	continuous delivery at any team size	DORA, trunkbaseddevelopment.com

What does the DORA research say about trunk-based development?

DORA, the research programme behind the four keys metrics, treats trunk-based development as one of its technical capabilities. Its capability page says analysis of the 2016 and 2017 survey data found that high performers had three or fewer active branches in the application's repository, merged branches to trunk at least once a day, and had no code freezes or integration phases. It ties those practices to better delivery speed, stability and availability, and it is clear about the preconditions: fast builds that finish in minutes, tests run before commit, and code review that happens promptly instead of sitting in a queue.

That last point matters more than people expect. A trunk-based team with a two-day review backlog is a GitFlow team with extra steps. The branch lives as long as the slowest reviewer, whatever the wiki says the strategy is.

The more recent DORA work points the same way from a different angle. The 2024 report estimated that as AI adoption increased, delivery throughput fell 1.5 percent and delivery stability fell 7.2 percent, and it attributed the gap to teams skipping basics "like small batch sizes and robust testing mechanisms". I went through the later DORA reports in DevOps Still Matters in 2026; the short version is that batch size is the variable AI makes easiest to get wrong.

Is GitFlow dead?

Not dead, but its author has narrowed its scope. In a note of reflection added to the original post in March 2020, Driessen wrote that teams doing continuous delivery should adopt "a much simpler workflow", naming GitHub flow, and kept GitFlow for software that is explicitly versioned or where you need to support multiple versions in the wild.

That is a fair line. If you ship a mobile app through store review, an on-premises product with customers on three major versions, or a library with LTS lines, release branches earn their keep. If you deploy a web service from main several times a day, a develop branch is a second trunk that drifts from the first, and every release becomes a merge of two histories nobody has tested together. Trunk-based teams that need release lines cut them from trunk, fix bugs on trunk first and cherry-pick down, which keeps the arrow of change pointing one way.

One small housekeeping note while we are on names: Git's breaking changes plan for Git 3.0 makes main the default branch for new repositories and moves new repositories to SHA-256, with no release date set yet. Git itself is at v2.56.0, tagged in September 2026.

How do merge queues make trunk-based development scale?

The failure mode of a busy trunk is the semantic conflict: two PRs that each pass CI against yesterday's main but break it together. Requiring branches to be up to date before merging fixes that, at the cost of everyone rebasing and re-running CI in turn. A merge queue does the rebasing for you.

GitHub's merge queue takes PRs that have passed branch protection, builds temporary branches that combine the target branch with every entry ahead in the queue, and only merges once the required checks pass on that combination. A failing entry is removed and the groups behind it are rebuilt. Build concurrency is configurable from 1 to 100. GitLab's equivalent, merge trains, is a Premium and Ultimate feature that runs up to 20 pipelines in parallel by default and requires merged results pipelines.

The one gotcha that catches every team on GitHub: required checks must also run on the merge_group event, or the queue waits forever for a status that never arrives.

# .github/workflows/ci.yml
# Runs on PRs and on the temporary branches a GitHub merge queue creates.
name: ci
on:
  pull_request:
  merge_group:          # without this, queued PRs never get their required check
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      # actions/checkout v7.0.1, pinned to the commit SHA
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
      - run: make test   # keep this under ~10 minutes or the queue becomes the bottleneck

The queue does not make slow CI acceptable. It makes slow CI visible, because the queue's throughput is roughly your build time divided by how many groups you run in parallel. My notes on speeding up GitHub Actions CI are the usual next step.

Stacked pull requests went native on GitHub in 2026

Small PRs are easy to recommend and annoying to produce when change three depends on changes one and two. Stacked diffs, popularised by Phabricator at Facebook, solve that: you open a chain of small PRs, each targeting the one below, and reviewers read one layer at a time.

Until this year that meant third-party tooling. Graphite was the best known, and Cursor bought it in December 2025. Then GitHub built it in. Stacked PRs reached public preview on 30 July 2026, with a stack map on each PR, per-layer diffs, automatic rebasing and retargeting when lower layers merge, and a CLI extension installed with gh extension install github/gh-stack. On 6 October 2026 they went generally available on all github.com plans, with a stack entering the merge queue as a single merge group and rebases that preserve approvals. GitHub Enterprise Server support is promised for an upcoming release, and auto-merge for stacks was still rolling out at GA.

Stacks are fully compatible with trunk-based development, and arguably its best friend. Each layer is a short-lived branch, branch protections still govern what reaches main, and the stack lets you keep integrating daily without waiting for the whole feature to be reviewed. The trap is a stack that grows to twelve layers and sits for two weeks: that is a long-lived branch wearing a disguise.

Feature flags: why trunk-based development needs them

If everything merges to trunk daily, unfinished features ship to production daily. Feature flags decouple deploy from release so that is safe, and branch by abstraction does the same for large refactors. I covered the tooling, including OpenFeature and flagd, in Progressive Delivery in 2026.

Flags have their own failure mode, and it is the best argument for deleting them. In the SEC's order on Knight Capital's August 2012 incident, the new code repurposed a flag that had once activated a retired function called Power Peg, which was still present on the one server out of eight that the deployment missed. In about 45 minutes that server built billions of dollars of unwanted positions, and Knight ultimately lost more than $460 million. A flag is a branch that lives in production; give each one an owner and an expiry date, and remove it with the same urgency you would delete a stale branch.

How do AI-generated pull requests change branching and review?

Volume is the obvious change. GitHub's Octoverse 2025 counted 518.7 million merged pull requests, up 29 percent, and more than a million PRs opened by Copilot's coding agent between May and September 2025. Agents default to GitHub flow: one branch, one PR, per task. That is fine for branching. What it breaks is review capacity, and review capacity is the thing DORA says has to stay fast for trunk-based development to work.

Review is also being automated. Since September 2026 Copilot code review can submit approvals that count toward required reviews, off by default, scoped by admins down to file paths, and dismissed when new commits arrive. Whether that is wise depends on what the paths are. I wrote about the gates I would keep in CI/CD in 2026.

My own rules for a trunk with agents on it are boring on purpose:

• Small batches for agents too. An agent PR over a few hundred lines gets split or sent back. Stacks make that cheap.
• A merge queue on the default branch. More parallel PRs means more semantic conflicts; the queue catches them before main does.
• The author cannot be the only approver. If an agent wrote it and a bot approved it, a human with ownership of those paths still signs off.
• Revert first, debug second. Trunk-based teams fix a broken trunk in minutes, which means reverting rather than rewriting history. The companion guide covers revert, reset and reflog in detail.

Platform discipline is what makes this boring. The branching model is a policy; branch protection, required checks, CODEOWNERS and the queue are how the policy is enforced when the PR author is a process rather than a person.

FAQ

What is the best Git branching strategy for a small team?

GitHub flow with short-lived branches, which is trunk-based development in practice. Protect main, require CI and one review, merge daily, and deploy from main. Add release branches only if you ship versioned software.

Is trunk-based development the same as committing directly to main?

Not necessarily. Very small teams may commit straight to trunk, but most use short-lived branches and pull requests for review and CI, merged at least once a day. The defining rule is that no branch lives long enough to drift.

Do I need a merge queue?

You need one when PRs regularly pass CI individually and break main together, or when "update branch" and re-run has become a daily ritual. On GitHub, remember to add the merge_group trigger to every workflow that provides a required check.

Are stacked pull requests compatible with trunk-based development?

Yes. Each layer is a short-lived branch that merges to trunk as soon as it is approved, and GitHub's native stacks now land through the merge queue as one group. Keep stacks short so they do not turn into long-lived branches.

This quarter I would do three things on any repository I own: turn on the merge queue and add merge_group to required workflows, try GitHub's native stacks for the next change that wants to be a 1,500-line PR, and audit feature flags older than ninety days. None of it is new advice. It is just cheaper to follow than it was a year ago.

Related: CI/CD in 2026: Agents Opened 1M PRs in 5 Months, Bots Write 1 in 5 Reviews, and Most Agent PRs Get No Human Look, Progressive Delivery in 2026: Feature Flags vs Canary vs Blue-Green and DevOps Still Matters in 2026: AI Cut Delivery Stability 7.2%, Then Doubled Merged PRs and Added 91% to Review Time.