GitHub flow
GitHub flow keeps ONE long-lived branch — main, always deployable — plus short-lived feature branches: open a pull request, pass CI and review, merge, deploy. No develop, no release branches. Fast for CD web apps, but assumes strong CI, quick review, and feature flags.
Take git-flow, delete develop, delete release branches, delete the whole versioning ceremony, and keep one rule: main is always deployable. What is left is GitHub flow — the workflow most small and medium product teams actually run, and the one GitHub built its own product on. It has exactly one long-lived branch and one short-lived branch type, and it fits a world where “release” just means “merge and deploy.”
By the end of this lesson you will be able to trace a change through GitHub flow’s single-branch model, name the three things it quietly assumes about your team, and say exactly how it differs from the git-flow you just learned.
After this lesson you can describe GitHub flow’s one-long-lived-branch model, trace a change from feature branch through pull request to deploy, and name the three preconditions — strong CI, fast review, and feature flags — that make it safe.
There is exactly one long-lived branch — main — and it is always deployable. This is the single rule everything else hangs on. Every commit on main is, by definition, something you could ship to production right now. There is no develop, no integration branch, no “code that is finished but not released yet” — finished is released. The job of the whole workflow is to protect that invariant: nothing reaches main unless it is reviewed, passing CI, and safe to deploy.
All work happens on short-lived feature branches, named for intent. When you start anything — a feature, a fix, an experiment — you branch off main:
git checkout main
git pull
git checkout -b add-csv-export
# ... commits ...
git push -u origin add-csv-exportThese branches live for hours or a day or two, not weeks. The branch name describes the change (add-csv-export, fix-login-redirect), and the branch exists only long enough to get the change reviewed and merged. Keeping it short is what stops it drifting far from main and causing the merge hell that long branches create.
A pull request is where review, CI, and discussion happen before merge. Pushing the branch, you open a pull request (PR) — a request to merge your branch into main. The PR is the workflow’s checkpoint: automated CI runs the test suite, teammates review the diff, and the conversation about the change is recorded next to it. On a protected main, the platform refuses the merge until required checks pass and the review is approved. The PR is GitHub flow’s entire quality gate — there is no release branch later to catch problems, so everything must be caught here.
Merge to main triggers deploy; the branch is then deleted. Once the PR is approved and green, you merge it into main. Because main is always deployable, that merge is the release — most teams wire continuous deployment so a merge automatically ships to production:
# after approval, merge via the PR (squash or merge commit), then:
git checkout main
git pull
git branch -d add-csv-exportThere is no tag-and-stabilise step, no merge-back-into-develop. Merge, deploy, delete the branch, move on. The simplicity is the point: from idea to production is one branch and one merge.
▸Why this works
What about work that is not finished but you still want to merge so the branch stays short? GitHub flow’s answer is the feature flag: merge the incomplete code to main behind a runtime toggle that is off in production. The code ships (so it is integrated and tested against everyone else’s work) but stays invisible to users until the flag is flipped on. This is how GitHub flow keeps branches short and avoids shipping half-finished features — the incompleteness lives in a flag, not in a long-lived branch. It is also the bridge to trunk-based development in the next lesson.
Shipping a CSV export on a Tuesday.
Tuesday morning you branch add-csv-export off a fresh main. You write the export plus tests, push, and open a PR by lunch. CI runs the suite (green) and a teammate reviews the diff, asks for one rename, you push the fix. Mid-afternoon the PR is approved and green; you merge. Your CD pipeline picks up the merge to main and deploys to production within minutes. You delete the branch. The feature was an idea at 9am and live by 3pm, and at no point did main contain anything un-deployable.
Compare this to git-flow: there the same change would merge into develop, wait for a release/1.x branch to be cut and stabilised, then merge into main and be tagged before deploying — days, not hours. GitHub flow trades git-flow’s versioning power for raw speed, which is exactly the right trade for a web app that does not have versions at all.
▸Common mistake
GitHub flow looks effortless, but it quietly assumes three things, and removing any one makes it dangerous. Strong CI: with no release branch to catch bugs, the PR’s automated tests are your only safety net, so they must be thorough and trustworthy. Fast review: short branches only stay short if PRs get reviewed in hours, not days — slow review silently turns GitHub flow into long-lived-branch hell. Feature flags: without them, “always deployable main” forces you to either keep big features on a long branch (defeating the model) or ship them half-done. Teams that adopt GitHub flow’s branch structure but skip these three preconditions get the simplicity on paper and the chaos in practice.
What is the defining structural difference between GitHub flow and git-flow?
GitHub flow keeps exactly one long-lived branch — main, always deployable — plus short-lived feature branches that open a pull request, pass CI and review, merge, and deploy. There is no develop and no release branch; finished means released. It is simpler and far faster than git-flow, which makes it the default for web apps doing continuous deployment and the workflow most small and medium product teams run. But it assumes strong CI, fast review, and feature flags for incomplete work — pull any of those and the simplicity collapses. Next you will see how high-velocity orgs push this idea even further with trunk-based development.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.