Topic 4.1
Branching Strategies: Git Flow, GitHub Flow, Trunk-Based
In one line
A branching strategy is a team's agreed-upon convention for how branches get created, named, and merged — the commands are identical either way, but the convention is what keeps a team's history coherent instead of chaotic.
Think of it like this
A shared kitchen with an agreed rule like 'label every dish with your name and the date' — the labeling itself isn't hard, but WITHOUT an agreed convention, everyone does it differently and nobody can find anything. A branching strategy is exactly this kind of agreed convention, applied to how a team uses branches.
Key ideas
- 01
GIT FLOW is a heavyweight, structured strategy with long-lived
developandmainbranches, plus dedicatedfeature/,release/, andhotfix/branch types, each with defined rules for where they branch from and merge back to. It was extremely popular historically and still fits projects with formal, scheduled release cycles (versioned software shipped periodically, not continuously). - 02
GITHUB FLOW is dramatically simpler:
mainis always deployable, every piece of work gets its own short-lived branch offmain, and a pull request merges it back intomaindirectly once reviewed — nodevelopbranch, no release branches. This fits teams that deploy continuously (multiple times a day or week) rather than on a fixed release schedule. - 03
TRUNK-BASED DEVELOPMENT pushes simplicity even further: everyone commits directly to
main(the 'trunk') extremely frequently, using very short-lived branches (often merged within hours) or even committing straight to main behind FEATURE FLAGS (a runtime toggle that hides unfinished functionality) rather than long-lived feature branches at all — favored by teams practicing continuous deployment at scale. - 04
There's no universally 'correct' strategy — Git Flow's structure suits teams shipping discrete, versioned releases (like a mobile app with app-store review cycles); GitHub Flow suits most modern web teams deploying continuously; trunk-based development suits teams with very mature automated testing and feature-flag infrastructure who want to minimize how long any branch lives before merging.
- 05
Whatever strategy a team picks, the genuinely important part is that everyone follows the SAME one consistently — a repository where half the team uses long-lived feature branches and the other half commits straight to main creates exactly the kind of confusing, inconsistent history that makes
git logandgit blamefar less useful for everyone.
Code & diagrams
Same underlying Git commands, three different levels of structure.
Explain it without notes
Why might a mobile app shipped through app-store review cycles benefit more from Git Flow than a continuously-deployed web service would?
What's the actual risk of a team having no agreed branching strategy at all, rather than everyone just 'doing what makes sense'?
Practice
Look at any real open-source project's repository on GitHub and try to identify, from its branch list and merge history, which of these three strategies (or a variant) it appears to be using.
For a hypothetical team you're familiar with (school project, work, personal), decide which of these three strategies would genuinely fit best, and write one sentence explaining why.
Trade-offs
- ↔
More structure (Git Flow) gives genuinely useful guardrails for complex, multi-version release management, at the cost of real overhead (more branch types, more merge steps) for a team that doesn't actually need it. Less structure (trunk-based) is fast and low-overhead but demands strong automated testing and feature-flag discipline to avoid
mainbreaking constantly — picking a strategy heavier or lighter than a team's actual needs is a common, avoidable source of process friction.
Done when you can
I can describe the core difference between Git Flow, GitHub Flow, and trunk-based development.
I can reason about which strategy fits a given team's release cadence and testing maturity.
I understand why consistency across a team matters more than which specific strategy is chosen.