Most arguments about branching are not really about Git. They are about how often you ship, who reviews what, and how much you trust your test suite. A team of four deploying a web app twice a day needs different habits from a team of four maintaining a library with a release every quarter. Three models come up again and again: Git Flow, trunk-based development and GitHub Flow. Each solves a real problem, and each adds friction when it is bolted onto the wrong team.

Git Flow: structure for scheduled releases

Git Flow, described by Vincent Driessen in 2010, gives you two permanent branches: main for what is released, and develop for what is coming next. Feature branches grow off develop. When you are ready to stabilise, you cut a release branch, fix bugs there, then merge into main and tag it. Hotfix branches come off main for urgent problems in production, and get merged back into develop so the fix is not lost.

The appeal is the map. Anyone can look at the repository and see what is in flight, what is being tested and what is live. It suits versioned software: desktop apps, mobile apps waiting on store review, libraries where older versions must keep working, or products with a formal QA gate and a monthly release train.

The cost is merge work. Develop drifts away from main, feature branches live for weeks and conflict with each other, and hotfixes have to be applied in two places. Bugs slip through because the code that ships is a merge commit nobody has run the full suite against. Small teams often end up spending more time reconciling branches than writing features.

Trunk-Based Development: commit small, commit often

Trunk-based development throws out long-lived branches. Everyone integrates into main at least once a day, and any branch lives for hours, not weeks. Unfinished work is hidden behind feature flags rather than kept on a private branch. Releases are tags on main, or simply the current state of main.

This works beautifully when continuous integration is genuine: a fast build, a test suite you trust, and a main branch that is never broken for long. Merges become small and boring, which is the whole point. Conflicts shrink to a few lines, defects surface within minutes, and turning a feature off is a config change rather than a revert.

It also demands discipline. Feature flags need owners and a cleanup date, otherwise your code fills with dead conditionals. Tests must run quickly enough that people actually wait. And if main breaks, everyone stops and fixes it: a red main is a team emergency, not a background task. If your test coverage is thin, trunk-based development will expose that on day one.

GitHub Flow: one branch, one pull request

GitHub Flow is the simplest of the three. Main is always deployable. You branch off main, commit, open a pull request, get a review, optionally deploy the branch to a staging environment, then merge and deploy. There is no develop branch and no release branch; the merge is the release.

It is easy to teach a new joiner in ten minutes, which matters more than it sounds. The pull request becomes the natural home for discussion, automated checks and screenshots. For web services with continuous deployment, it fits neatly.

Where it strains is anything that needs a "next version" shelf. Work that cannot ship yet has to hide behind flags or wait. Supporting two released versions at once is awkward, since there is no branch to patch. And on a busy repository, unreviewed pull requests pile up, so a slow review culture turns GitHub Flow into a queue rather than a pipeline.

Choosing between them

Skip the ideology and answer a few concrete questions about your team:

• How often do you release? On every merge points to GitHub Flow or trunk-based. Monthly, with sign-off, points to something closer to Git Flow.
• Do you maintain old versions? If customers run 2.x while you build 3.x, you need release branches and hotfix paths.
• How reliable is your CI? A slow or flaky suite rules out aggressive trunk-based working until it is fixed.
• How fast are reviews? If a pull request waits two days for approval, branches get long and merges get painful, whatever model you claim to use.
• How many people touch the same files? More overlap means shorter branches matter more.

A sensible middle ground for many small teams is GitHub Flow plus tags, adding a release branch only when an old version genuinely needs patching. That keeps daily work simple while leaving a door open for maintenance.

Habits that make any model work

The branch model is the easy part. These habits decide whether it succeeds:

1. Keep branches short. If a branch is older than a week, split the work or hide it behind a flag.
2. Protect main. Require a passing build and at least one review before merging.
3. Make one branch do one thing. Mixed-purpose branches are hard to review and worse to revert.
4. Delete branches after merging. A tidy branch list is a working branch list.
5. Agree on naming, such as feature/billing-export or fix/login-timeout, so scripts and filters behave predictably.
6. Write a definition of done: tests pass, docs updated, flag created, reviewer assigned.
7. Review the rules each quarter. Teams outgrow models quietly, and the friction shows up as slow releases rather than complaints.

What to do this week

Pick the smallest change that removes your worst pain. If merges are the problem, shorten branch lifetimes before changing anything else. If releases are chaotic, add a release branch and a checklist. If nobody knows what is deployed, make main deployable and tag every release.

Write the model down in the repository README: branch names, who merges, how hotfixes work, how long a branch may live. Then try it for a month and count two things: how long it takes from finished code to production, and how often main is broken. Those numbers will tell you more about the right strategy than any diagram.

Photo: StartupStockPhotos / Pixabay