GitHub flow vs git flow: which branching model fits your team, and what it means for a PM

GitHub flow vs git flow, in short: GitHub flow keeps one long-lived branch, main, that is always ready to go live, and every change reaches it through a short-lived branch and a pull request, usually followed by a deploy within minutes. Git flow keeps two long-lived branches, main for released versions and develop for the next one, plus separate branches for features, releases and hotfixes, and ships on a schedule. GitHub flow fits websites and web apps that deploy continuously; git flow fits products where a release is an event, such as mobile apps that go through store review or software customers install themselves. For a product manager the biggest difference is one word: in GitHub flow "merged" usually means "live soon", in git flow it means "in the next version".

A quick case: one word, two meanings

CatChow, an online pet-food shop, works in GitHub flow. When Daniel, a web developer, squash-merged the fix for a stuck checkout button at 9:40, an automatic deploy put it on the live site at 9:44. Merged and live were four minutes apart, and nobody had to press anything.

In his previous job Daniel built a fitness app for phones, and that team used git flow. A new version went out every two weeks, and each one went through Apple's and Google's review first. When workout reminders were merged in the middle of a sprint, they landed on develop, not on the version users had. They reached people's phones almost two weeks later. More than once, marketing saw "reminders merged" in the team chat and started preparing an announcement for a feature nobody could use yet.

Same button, same word, very different meaning. Knowing which model your team uses tells you how to read every status update.

GitHub flow in plain words

1. main always holds a version that could go live right now.
2. For each change, someone creates a short-lived branch from main, for example fix/checkout-button.
3. They commit the change there and open a pull request into main.
4. Reviewers comment and approve; automated checks run.
5. The pull request is merged and the branch is deleted.
6. The new main is deployed, in many teams automatically.

Branches live days, not weeks, and pull requests stay small enough to review in one sitting. Anything that isn't ready for customers either waits on its branch or is merged hidden behind a feature flag: a switch that turns a part of the product on or off without a new deploy.

Git flow in plain words

Git flow comes from Vincent Driessen's 2010 article "A successful Git branching model". It has five kinds of branches:

When develop holds enough for the next version, someone "cuts" a release branch, say release/2.8.0. Testers work on it while develop keeps accepting features for the version after. When it's ready, the release branch is merged into main, tagged, and merged back into develop so its fixes aren't lost. A hotfix follows the same double path: into main with a new tag such as v2.7.1, and into develop, or into the open release branch if there is one. Forget that second merge, and the next version brings the bug back.

GitHub flow vs git flow side by side

Where trunk-based development fits

There is a third model you will hear about. In trunk-based development everyone merges small changes into main (the "trunk") at least once a day, branches live hours rather than days, and feature flags hide whatever isn't ready. It is GitHub flow taken further: even faster, and only safe with very good automated tests and strong team discipline.

In 2020 Driessen added a note to his own article: for web apps delivered continuously, he suggested something simpler like GitHub flow, and kept git flow for software that is explicitly versioned. Many web teams made exactly that move.

Which one fits your product

Git flow tends to fit when:

• a release has to pass someone else's review, as in the app stores;
• customers install and update the software themselves, so several versions live at once;
• you support older versions with fixes, for example for enterprise clients;
• releases are coordinated with marketing, legal or partners on a fixed date.

GitHub flow tends to fit when:

• there is only ever one version live, like a website;
• the team can deploy many times a day with a safe way back (revert or a flag);
• you want feedback from real users as soon as each small change is ready.

A web team that adopts git flow mostly buys waiting and double merges. A mobile team without release branches has nowhere to stabilise a version while new work keeps coming in. And version numbers don't require git flow: a GitHub flow team can tag a release every week on top of continuous deploys.

How to tell which model a repository uses

Open the repository's branches page and look for three signs:

• The default branch. If it's develop, new pull requests go there by default: git flow.
• Branch names. release/… and hotfix/… next to develop mean git flow. Only main plus a handful of fresh fix/…, feature/… or content/… branches mean GitHub flow. Branch names are a team habit, not a Git rule, so treat them as a strong hint, not proof.
• Where pull requests go. A merged pull request says which branch it was merged into. "Merged into develop" means the change is waiting for a release.

A branch list like this one is git flow in textbook form:

develop          Default · updated today
main             Updated 9 days ago · tag v2.8.0
release/2.9.0    Updated yesterday
feature/step-goals   Updated 2 hours ago · pull request into develop
hotfix/2.8.1     Updated 1 hour ago · pull request into main

If main is almost the only branch, branches live for hours and the codebase is full of flags, you are looking at trunk-based development. When in doubt, ask one developer one question: "How does a merged change reach customers here?"

What it changes for a PM

Answering "is it live?" In GitHub flow, check that the pull request is merged into main and that the deploy after it finished; many repositories show this under Deployments on the repository page (as of 2026). Then check whether a feature flag hides it. In git flow, the question becomes "which version is it in, and has that version reached users?"

Planning. Git flow gives you a calendar, and the cut date becomes the most contested date of each cycle: a feature merged a day late waits for the next train. GitHub flow gives you a stream: plan in small slices that can each ship on their own, and use flags to decide when customers see them.

Announcing. In git flow, never announce on "merged". In GitHub flow, announce on "flag on", not on "merged", when a flag is involved.

Reviewing. Small pull requests are what make GitHub flow safe. If a pull request touches sixty files for "a small tweak", ask why; the review guide in how to review a pull request covers how.

Common mistakes

Switching to git flow to get "proper releases". Usually what's wanted is to know what changed and when. Version tags and release notes give you that without develop.

Long-lived branches in GitHub flow. A feature branch untouched for months, dozens of commits behind main, is GitHub flow in name only. Rebuild it in small pull requests behind a flag instead of merging it in one go.

Forgetting to remove flags. Every flag is an extra "if" in the code. Once a feature is on for good, the flag should go.

What to do this week

1. Open your product's repository and check the default branch and the branch names.
2. Look at the last three merged pull requests: which branch were they merged into?
3. Ask a developer how and when a merged change reaches customers, and whether the team uses feature flags.
4. Write the answer down in one sentence for your marketing and support colleagues.

Key takeaways

• GitHub flow: one long-lived main, short branches, pull requests, deploy on merge.
• Git flow: main plus develop, with feature, release and hotfix branches and a release calendar.
• GitHub flow fits continuous web deploys; git flow fits scheduled, versioned releases.
• Trunk-based development is the fastest end of the scale and leans hard on flags and tests.
• For a PM the model decides what "merged" means. Find out before you announce anything.

FAQ

Is git flow outdated?

Not for every product. It still fits mobile apps, installed software and teams that support several versions. For continuously deployed web products most teams prefer GitHub flow or trunk-based development, and the model's author said much the same in 2020.

Does GitHub flow have versions and releases?

It doesn't require them, but you can add them. A team can deploy every merge and still tag a version and publish release notes every week, so everyone can say "fixed in 1.4.1".

Can a team mix the two models?

Yes, and many do: GitHub flow day to day, with a short-lived release branch when a big launch needs a few days of stabilisation. What matters is that everyone knows which branch customers are running.

What does "merged into develop" mean for my feature?

That it is finished and accepted for the next version, not that users have it. It reaches users when a release containing it is cut, tested, merged into main and shipped.

Learn it hands-on

The lesson GitHub flow: small branches, fast merges follows CatChow's changes from branch to deploy, including a sale banner merged behind a flag. Git flow: develop, release and hotfix branches reads a mobile team's history lane by lane, and Branches covers what a branch is and how to read "ahead" and "behind". All three are part of the free course Git and GitHub for Product People.