AdvancedIn-depth3 min readUpdated 2 Oct 2026

What branching strategies do teams use in Git? Compare GitFlow and trunk-based development.

SHORT ANSWER

Most teams use short-lived feature branches merged through pull requests. GitFlow adds long-lived develop, release and hotfix branches and suits planned, versioned releases. Trunk-based development keeps everyone merging small changes into main at least daily, using CI and feature flags, and suits teams that deploy often.

Explain it simply

A branching strategy is the team's agreement on which branches exist, who creates them, and how code moves from a developer's laptop to production. Without one, people push half-finished work to main, nobody knows what is deployed, and releases become stressful.

There are three common answers:

Feature branches (GitHub flow): main is always deployable. For each task you create a branch, open a pull request, get it reviewed, and merge it back. Simple and widely used.
GitFlow: more structure, with a develop branch for ongoing work and separate release and hotfix branches.
Trunk-based development: everyone merges very small changes into main (the "trunk") often, at least once a day. Unfinished features hide behind feature flags.

Example

GitFlow for a mobile banking app that ships version 3.2 every month:

text

main      ──●───────────────●──────●──    (tagged releases: v3.1, v3.2, v3.2.1)
             \             / \    /
hotfix        \           /   ●──●        (hotfix/3.2.1)
               \         /
release         \   ●──●                 (release/3.2: only bug fixes)
                 \ /    \
develop   ──●──●──●──●───●──●──          (integration branch)
             \   /
feature       ●─●                        (feature/upi-autopay)

Trunk-based for a food delivery web app that deploys many times a day:

bash

git switch -c add-tip-option     # branch lives for a few hours
# small change, behind a flag that is off in production
git commit -am "Add tip option behind flag"
git push -u origin add-tip-option
# open PR, CI passes, quick review, merge to main the same day

How it works

	GitFlow	Trunk-based
Long-lived branches	`main`, `develop`	Only `main`
Branch lifetime	Days to weeks	Hours to a day or two
Release	Cut a `release/x.y` branch, stabilise, merge to `main` and tag	Deploy `main` continuously, or cut release branches from it
Unfinished work	Stays on feature branch	Merged but hidden by feature flags
Needs	Release discipline	Strong automated tests and CI
Merge conflicts	Larger, less frequent	Small, frequent

GitHub flow sits in between: only main plus short feature branches, every merge goes through a pull request, and main is deployed after merging.

Real-world use

Products with app-store releases, on-premise installs or several supported versions often use GitFlow or a release-branch variant.
Web products with good test coverage, common in product companies and startups, lean towards trunk-based or GitHub flow, because long branches slow them down.
In service companies, the client often decides the strategy; you may see GitFlow-style naming like feature/, release/ and hotfix/ on Bitbucket or Azure DevOps.

Common mistakes

Choosing GitFlow for a small web app that deploys daily. The extra branches add ceremony without benefit.
Calling it "trunk-based" while keeping feature branches open for three weeks. The point is small, frequent merges.
Forgetting to merge a hotfix back into develop in GitFlow, so the bug returns in the next release.
Using trunk-based development without feature flags or tests, so half-built features reach users.

What to say in the interview

"The common base is feature branches merged through pull requests, with main kept deployable. GitFlow adds a develop branch plus release and hotfix branches; it works well for scheduled, versioned releases like mobile apps, but it creates long-lived branches and bigger merges. Trunk-based development has everyone merge small changes into main at least daily, relies on CI and feature flags, and fits teams that deploy continuously. I'd choose based on release frequency and test maturity. For most web teams today, short-lived branches with trunk-based habits work best."

Follow-up questions

What is a feature flag, and what problem does it solve?
How do you handle an urgent production bug in GitFlow?
How do branch protection rules support a branching strategy?
What is the difference between continuous delivery and continuous deployment?

Go deeper

Read these once the basics above feel easy.

Branch protection on GitHub enforces the strategy: require a pull request before merging to main, require passing status checks, require at least one approval, and block force pushes. Tags such as v3.2.0 mark exactly what was released, so you can always rebuild or hotfix that version.

The DORA research on software delivery has associated trunk-based development with higher delivery performance, mainly because small batches are easier to review, test and roll back. The trade-off moves complexity into runtime: feature flags need owners and clean-up, or the code fills up with dead branches of logic. Many mature teams use trunk-based development day to day and still cut short-lived release branches from main when they need to stabilise a specific version.

#git #branching #gitflow #trunk-based #workflow