What is a good Git branching strategy and how do Git Flow and trunk-based development differ?
Compare Git Flow and trunk-based development, learn what makes a good Git branching strategy, and see when to use each with examples and interview tips.
Expected Interview Answer
A good branching strategy is a team agreement on how branches are created, merged, and released so work stays organised and mainline stays releasable; Git Flow uses many long-lived branches (main, develop, feature, release, hotfix) while trunk-based development keeps everyone committing to a single main branch with very short-lived branches.
Git Flow suits scheduled, versioned releases: features merge into develop, a release branch stabilises, then merges to main and is tagged, with separate hotfix branches for production fixes. Trunk-based development suits continuous delivery: developers integrate small changes into main many times a day behind feature flags, avoiding long-lived divergence and painful merges. The right choice depends on release cadence, team size, and CI/CD maturity, not on fashion.
- A shared strategy prevents merge chaos and unclear release state
- Git Flow gives clear structure for versioned, scheduled releases
- Trunk-based enables continuous integration and fast delivery
- Short-lived branches reduce merge conflicts and integration debt
- Feature flags let unfinished work ship to main safely
- Clear release/hotfix paths make production fixes predictable
AI Mentor Explanation
Git Flow is like a national board running age-group, domestic, and Test squads as separate long-standing teams that feed talent upward through scheduled selection windows. Trunk-based development is like a single first-team net session where every player integrates into the one squad daily, tiny adjustments merged in continuously. Both organise players, but one keeps many parallel squads while the other keeps one mainline everyone joins.
Step-by-Step Explanation
Step 1
Assess release cadence
Scheduled versioned releases favour Git Flow; continuous delivery favours trunk-based.
Step 2
Define the mainline
Decide whether 'main' is always releasable (trunk) or fed by 'develop' (Git Flow).
Step 3
Standardise branch types
Agree naming and purpose: feature/, release/, hotfix/ for Git Flow; short feature branches for trunk.
Step 4
Set merge and review rules
Require pull requests, passing CI, and code review before merging into protected branches.
Step 5
Adopt feature flags for trunk
Ship unfinished work to main safely by gating it behind toggles instead of long branches.
Step 6
Define hotfix path
Document how urgent production fixes are branched, merged, and tagged.
What Interviewer Expects
- A clear definition of what a branching strategy is and why it matters
- Accurate description of Git Flow's branch roles
- Understanding of trunk-based development and short-lived branches
- Awareness that feature flags enable trunk-based CI
- Ability to pick a strategy based on release cadence and team maturity
Common Mistakes
- Claiming one strategy is universally best regardless of context
- Confusing 'develop' and 'main' roles in Git Flow
- Letting feature branches live for weeks, causing merge hell
- Thinking trunk-based means no branches at all
- Ignoring the role of CI/CD and feature flags in trunk-based work
Best Answer (HR Friendly)
“A branching strategy is the team's agreed way of organising code changes so releases stay smooth. Git Flow uses several long-lived branches for scheduled releases, while trunk-based development keeps everyone working on one main line for fast, continuous delivery.”
Code Example
git checkout develop
git checkout -b feature/user-auth
# work, commit, then integrate
git checkout develop
git merge --no-ff feature/user-auth
# prepare a release
git checkout -b release/1.2.0 develop
git checkout main && git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"git checkout main && git pull
git checkout -b fix/login-typo
# small change, commit, open PR
git push origin fix/login-typo
# after review + green CI, merge to main and delete
git checkout main && git merge --ff-only fix/login-typo
git branch -d fix/login-typoFollow-up Questions
- When would you choose Git Flow over trunk-based development?
- How do feature flags make trunk-based development possible?
- What is GitHub Flow and how does it compare to both?
- How do you keep short-lived branches from causing merge conflicts?
- How does branch protection support a branching strategy?
MCQ Practice
1. Which branch does Git Flow use to accumulate completed features before a release?
In Git Flow, feature branches merge into 'develop', which is stabilised via a release branch before merging into 'main'.
2. What technique lets trunk-based teams merge unfinished work into main safely?
Feature flags gate incomplete features so they can live in main disabled until ready, avoiding long-lived branches.
3. A key difference between trunk-based and Git Flow is that trunk-based favours:
Trunk-based development integrates small changes into main frequently using very short-lived branches.
Flash Cards
What is Git Flow? — A strategy with long-lived main, develop, feature, release and hotfix branches for scheduled releases.
What is trunk-based development? — Everyone integrates small changes into one main branch frequently via very short-lived branches.
How does trunk-based ship unfinished work? — Behind feature flags that keep code disabled in main until it is ready.
Which suits continuous delivery? — Trunk-based development, because frequent small merges keep main always releasable.