Q29 of 40 · Git

Compare Gitflow and trunk-based development — what are the QA testing implications of each?

GitMidgitgitflowtrunk-basedbranchingworkflowcicd

Short answer

Short answer: Gitflow uses long-lived feature/develop/release branches — QA tests each branch independently, enabling thorough gating but risking integration surprises at merge time. Trunk-based dev merges small commits to main frequently — QA relies on feature flags and automated gates; integration issues surface earlier.

Detail

Gitflow defines a structured set of branches: main (production), develop (integration), feature/* (new work), release/* (stabilisation), hotfix/* (emergency fixes). QA owns the release/* branch — testers have a stable snapshot to regression-test against, and a clear handoff point. The downside is that feature branches can diverge for weeks, and the merge to develop may introduce surprise integration failures that are costly to resolve late.

Trunk-based development (TBD) requires all developers to merge to main (the "trunk") at least once per day, using short-lived feature branches (< 1 day) or direct commits with feature flags. QA testing shifts left: every commit runs the full automated test suite in CI. There is no "QA phase" — testing is continuous. Feature flags allow incomplete features to be deployed but hidden, so QA can test in production-like environments without blocking other features.

QA implications of TBD: (1) automated regression coverage must be very high because there is no manual gating phase; (2) test execution time matters (slow test suites break the frequent-merge model); (3) flaky tests are more visible and more damaging. QA engineers own test reliability as much as test creation.

Which to recommend: TBD with CI/CD is the modern default for teams shipping frequently. Gitflow is still common in regulated industries (pharma, finance) where release artefacts must be immutable and audit-trailed.

// EXAMPLE

# --- Gitflow branch setup ---
git switch -c develop main
git switch -c feature/payment-api develop
# ... work ...
git switch develop
git merge --no-ff feature/payment-api
git switch -c release/v2.5 develop
# QA tests release/v2.5 here
git switch main
git merge --no-ff release/v2.5
git tag -a v2.5.0 -m "Release 2.5.0"

# --- Trunk-based development ---
# Short-lived branch (hours, not days)
git switch -c add-payment-retry main
# ... small focused change ...
git push origin add-payment-retry
# Open PR → CI runs → auto-merge if green → deleted
# Feature flag controls visibility in production:
# if (featureFlags.isEnabled("payment-retry", userId)) { ... }

// WHAT INTERVIEWERS LOOK FOR

Concrete QA implications of each model (gating phase vs continuous testing). Understanding feature flags as a TBD enabler. Knowing that flaky tests are a first-class problem in TBD. Recognising regulated-industry use cases for Gitflow.

// COMMON PITFALL

Assuming trunk-based development means no testing — it actually requires MORE automated test coverage, not less, because there is no manual QA gate.

// Related questions

As a QA lead, how would you configure branch protection rules for `main` and `release/*` branches to enforce quality gates without slowing down the team?

Git

How do you balance fast feedback (PR-time tests) with comprehensive coverage (nightly tests)?

CI/CD & DevOps

What is the difference between a fast-forward merge and a no-fast-forward (--no-ff) merge, and which should a QA team prefer?

Git