Choosing a Git workflow: a decision guide for real teams
Trunk-based, Gitflow, GitHub Flow, GitLab Flow, Release Flow — five workflows, three questions about your team, one matrix that tells you which to use. With evidence and real examples.
You join a 12-person team. On your first day, someone tells you "we use Gitflow, but kind of modified." Three weeks later you are trying to merge a release branch into develop, after someone cherry-picked a hotfix from main, and nothing matches the diagrams you read online.
This happens to almost everyone. Most teams pick a Git workflow once, never write it down clearly, and then drift. New people inherit the drift. Soon nobody can explain why the team works the way it does — only how.
This post is a guide to picking the right workflow on purpose. There are five common workflows. There are three questions about your team that decide which one fits. Get the fit wrong and Git fights you every day. Get it right and Git becomes invisible.
The three questions that decide everything
Your team's Git workflow is decided by three questions. Just three.
1. How big is your team?
- Solo (just you)
- Small (2–10 people)
- Medium (10–50 people)
- Large (50+ people)
2. How is your code organised?
- One repository (the simplest case)
- Many small repositories (one per service or team)
- One huge repository — a "monorepo"
3. How often do you ship to production?
- Many times a day ("continuous deployment")
- Once a day
- Once every 1–2 weeks (the typical "sprint" cadence)
- Once a month or slower (often "versioned" releases like v1.5, v2.0)
That is the whole framework. Three questions. Everything else follows.
Picking the wrong answer for any of them has a real cost. Some examples:
- A 4-person team using Gitflow ends up spending more time moving code between branches than writing code.
- A 50-person team using one shared branch with no rules ends up with constant merge conflicts and a frequently broken
main. - Three separate repositories that need to ship together get out of sync — you change something in repo A but forget the matching change in repo B, and production breaks.
If you read no further than this section, you already have the framework. The rest of this post explains the workflows and shows you the matrix.
What the data says
Most Git workflow advice online is opinion dressed as fact. One study is not.
The State of DevOps Report — known as DORA after the research group that runs it — has studied thousands of engineering teams every year since 2014. They found one strong pattern: high-performing teams use short-lived branches. Their feature branches live for less than a day, on average. Low-performing teams have branches that live for weeks.
Source: DORA 2018 State of DevOps Report.
What does this mean for you?
- If your team deploys often (daily or more), keeping branches short is strongly supported by evidence.
- If your team releases slowly (every few months), long branches are not automatically wrong. They may match your cadence.
An honest caveat. The DORA study shows correlation, not causation. Short branches do not magically make a team high-performing. They are a habit that high-performing teams have, alongside other habits — test automation, code review culture, deployment automation. Treat "short branches" as one ingredient in a recipe, not as a silver bullet.
The five workflows
This section is reference material. Five workflows, what each one looks like, where each came from. Read the one your team uses (or wants to use) and skim the rest.
1. Trunk-Based Development (TBD)
Everyone works on one shared branch called main (the "trunk"). Feature branches exist but live for hours, not days. Unfinished work is hidden behind feature flags — small if (featureFlag.enabled) switches in code that you can turn on later.
It looks something like this:
# Monday morning
git checkout -b add-search-button
# ... 3 hours of work, with feature flag wrapping the new code ...
git push origin add-search-button
# open PR, get review, merge to main same day
If you have ever collaborated on a Google Doc, you already understand the spirit. Everyone edits the same document. Edits are small and frequent. Conflicts, when they happen, are tiny and easy to resolve.
Best for: any team that deploys often. Most modern web companies. Reference: trunkbaseddevelopment.com by Paul Hammant.
2. Gitflow
Two long-lived branches: main (what is in production) and develop (where new work integrates). Plus short-lived branches for features (feature/*), upcoming releases (release/*), and emergencies (hotfix/*).
Work flows through structured stages. A feature is built on a feature/ branch, merged into develop, then a release/ branch is cut for QA, then merged into both main and back into develop at release time. Hotfixes branch from main, get fixed, and merge back into both main and develop.
It is the most structured of the five workflows. It is also the most expensive in time and overhead.
Best for: products that ship on a schedule with versions — a desktop app that releases v1.5, v1.6, v2.0; an SDK with semver guarantees; embedded software on a quarterly cadence. Reference: Vincent Driessen's original 2010 post. Note: in 2020, Driessen himself added a note to that post saying "If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow." He didn't kill Gitflow — he scoped it.
3. GitHub Flow
One branch (main). Make a branch, do the work, open a pull request, get it reviewed, merge. Then deploy.
git checkout -b fix-login-bug
# ... work ...
git push origin fix-login-bug
# open PR on GitHub, review, merge → main is ready to deploy
That is the entire workflow. There is no develop branch. There are no release branches. If main is broken, nobody deploys until it is fixed.
Best for: web apps and teams that can deploy whenever they want. Reference: GitHub's official docs.
4. GitLab Flow
GitHub Flow plus extra branches for environments. Common pattern:
main— where new work is merged after reviewpre-production— what is on the staging serverproduction— what is live for users
Code moves forward through these branches in order: main → pre-production → production. No backwards merges, no surprises.
Best for: teams that cannot deploy on every merge — for example, when a separate QA team approves releases, or when an external compliance step (App Store review, security sign-off) gates production. Reference: GitLab's docs.
5. Release Flow (Microsoft)
Like Trunk-Based Development, but with long-lived release branches added on. New work goes into main. When you're ready to ship a version, you create a branch like release/2026.06 from main. After that, only specific bug fixes (cherry-picked from main) make it into the release branch.
It tries to give you the best of both worlds: a fast-moving trunk where development happens, and stable release lines that can receive patches without forcing every user onto the latest version.
Best for: medium-to-large teams shipping versioned software (Azure DevOps itself uses this). Reference: Microsoft's branching guidance.
The decision matrix
Here is the table that ties it all together. Find your team size on the left, your release cadence on the top, and read the recommended workflow.
| Many deploys per day | Daily | Every 1–2 weeks | Monthly or slower | |
|---|---|---|---|---|
| Solo (1) | TBD | TBD | TBD | TBD + tags |
| Small (2–10) | TBD + feature flags | TBD or GitHub Flow | GitHub Flow | GitLab Flow |
| Medium (10–50) | TBD + merge queue + flags | TBD + merge queue | GitHub Flow + tags | Release Flow or GitLab Flow |
| Large (50+) | TBD + merge queue + flags | TBD + merge queue | Release Flow | Gitflow |
A few cells need explanation.
Small team, many deploys per day → TBD + feature flags. Small teams move fast and don't need extra structure. The simplest workflow wins. Feature flags let you ship unfinished work safely — turned off in production until ready.
Medium team, anything fast → TBD + merge queue. A "merge queue" (GitHub's merge_group event, generally available since July 2023) automatically tests every PR against the latest main before merging it. This prevents the case where two PRs each pass their own tests, get merged minutes apart, but together break main. At 10–50 engineers, that case happens weekly without a merge queue.
Large team, monthly or slower releases → Gitflow. When you ship a versioned product to thousands of customers — an SDK, a desktop app, embedded firmware — release branches earn their cost. You need v2.4 to be able to receive a security patch six months after v2.5 ships, without forcing every customer to upgrade. That capability is what release branches give you, and Gitflow is the most documented way to manage them.
Most real teams are not at extremes. Pick the row and column closest to yours, and adjust from there. The matrix is a starting point.
Where your code lives — a separate question
This is a different question from "which workflow," and it is worth being clear: repo shape changes how you run a workflow, not which workflow you pick.
- One repository is the simplest. All code in one place. Easy to clone, easy to search.
- Many small repositories — one per service or one per team. Independence is the upside; coordinating changes that touch multiple repos is the downside.
- One huge repository (a monorepo) — used by Google, Meta, Stripe. All code in one repo, with many projects inside. Atomic cross-project changes are easy. The repo gets large, so you need special techniques (sparse checkout, partial clones) to stay fast.
A quick rule of thumb:
| Situation | Try |
|---|---|
| 1–5 services, single team | One repository |
| 5–20 services that often change together | Monorepo |
| 20+ services, very different teams that rarely touch each other | Multi-repo |
Posts #5 and #6 of this series cover monorepo and multi-repo techniques in depth.
Three real teams
Abstract advice is hard to apply. Here are three real-shape teams and the workflow each one uses.
Team 1: Two-person startup, SaaS web app. One repository. Deploys many times a day. The two founders pair-program most of the time; code review happens out loud.
Workflow: Trunk-Based Development. They commit directly to main when pairing. When working alone, they make a short branch, open a PR for the partner to review, and merge within hours. Feature flags hide work-in-progress from real users. The whole Git workflow fits in one paragraph of their README.md.
Team 2: Thirty engineers, Series B startup, B2B product. Monorepo with about 40 services inside. Deploys go out 10–20 times per day.
Workflow: Trunk-Based Development + merge queue + feature flags. Engineers open PRs on main. A CODEOWNERS file says which engineer must review which folder — payments code requires a payments reviewer, infra code requires an infra reviewer. The merge queue auto-tests each PR against the latest main before merging. Feature flags are managed by a shared library so any engineer can turn one on or off via a dashboard.
Team 3: 120 engineers, mobile SDK. Multi-repo (each platform — iOS, Android, Web — has its own repo). Quarterly major releases (v3.0, v3.1) plus monthly minor releases.
Workflow: Gitflow. Each major release gets its own release/3.0, release/3.1 branch that survives for months. When a security bug is found in v3.0 — used by thousands of customer apps that have not yet upgraded to v3.1 — the team can ship 3.0.1 from release/3.0 without breaking anyone's downstream code. The structure is heavy. It earns its weight.
When to break the rules
The matrix is a starting point, not a law. Some honest reasons to deviate from it:
Regulated industries. Medical software, financial trading, aerospace — these often require workflows with formal audit trails for every change. A small medical-device team may run Gitflow for compliance reasons that have nothing to do with team size.
Tooling you don't yet have. Trunk-Based Development depends on feature flags and good automated testing. A team with neither — but who reads online that TBD is "the modern way" — will hurt themselves by jumping to TBD before they have the safety net. Add the safety net first.
Existing habits. A team that has run Gitflow for five years cannot switch to TBD overnight. Migration takes weeks of small changes, not one big rewrite. The last post in this series (#8) is a full migration playbook.
Common myths
Three things you will read on the internet that are wrong.
Myth 1: "Gitflow is dead." Wrong. Gitflow is no longer the right default for most teams, but it is still the right choice for some. Driessen narrowed its recommended use in 2020 — he did not deprecate it.
Myth 2: "TBD means every commit goes to production." Wrong. TBD requires every commit on main to be safe to deploy — not that you actually deploy every commit. Many teams using TBD deploy on a schedule (twice a day, once a week). The point is that main is always shippable, not that it is always shipped.
Myth 3: "Monorepos require Bazel." Mostly wrong. For a small or medium monorepo, normal tools (sparse checkout, path-based CODEOWNERS, conditional CI) work fine. Bazel solves build speed at huge scale — it is a build-system answer to a build-system problem, not a Git workflow tool. Most monorepos do not need it.
What to read next
This is the first post in a series on Git strategy. The other seven posts go deeper into the topics this one introduced:
- Trunk-Based Development: when it wins and when it doesn't — when TBD fits, when it does not, what feature-flag infrastructure you need first.
- Gitflow in 2026: still useful, or time to move on? — a deeper look at when Gitflow earns its weight, with side-by-side comparison to GitHub Flow and GitLab Flow.
- Scaling a Git workflow from solo to large team — what changes when teammate #1 joins, what changes again at 10, at 50, and at 100.
- Monorepo Git techniques — sparse checkout, partial clones, commit-graph, fsmonitor, CODEOWNERS sharding.
- Multi-repo coordination — submodules, subtrees, and internal package registries compared honestly.
- Release branches and hotfix workflows — the mechanics of parallel timelines without losing work.
- Migrating from Gitflow to Trunk-Based Development — a step-by-step playbook for changing strategies on a working team.
In the meantime, if you want to feel how Trunk-Based Development actually works in your hands, the Trunk-Based Dev lesson below opens a live terminal where you can practise the short-branch, fast-merge rhythm in two minutes.