Q31 of 40 · Git

Design a Git branching and tagging strategy for a 5-team QA organisation that needs to test features independently and also run full regression across all features before release.

GitSeniorgitworkflowbranchingqa-strategyreleasetagging

Short answer

Short answer: Use trunk-based dev with short-lived feature branches per team, a shared `integration` branch for cross-team regression, and immutable release tags. Feature flags decouple merge from activation. CI enforces test gates at each stage.

Detail

A practical model for a multi-team QA org combines the discipline of trunk-based development with explicit integration and release milestones.

Branch structure:

  • main (trunk): protected, always deployable. All feature branches merge here via PR.
  • feature/team-A-* (short-lived, < 1 week): each team develops and unit/component tests on their branch. Auto-deleted after merge.
  • integration (optional, refreshed weekly): created from main at the start of a regression cycle. All teams merge their features here. Full regression suite runs against integration — this is the shared stage for cross-feature testing. Not rebased; only merged into.
  • release/vX.Y: cut from integration after regression passes. Only hotfixes go in. Tagged with vX.Y.0, vX.Y.1, etc. (annotated tags, immutable once published).

Feature flags: features on main are behind flags — the integration branch can activate them all together for regression without blocking individual team merges.

CI gates:

  1. PR into main: unit + component tests (< 5 min).
  2. Nightly on main: full automated regression.
  3. On integration branch creation: full regression + cross-feature smoke.
  4. On release/* cut: smoke + performance baseline.

Tagging: git tag -a v2.5.0 -m "Release 2.5.0" <sha> on the release commit. Tags are signed (-s) in high-compliance environments.

// EXAMPLE

# --- Weekly integration cycle ---

# Create integration branch from current main
git switch main && git pull --rebase
git switch -c integration/2025-w21 main
git push origin integration/2025-w21

# Each team merges their feature branch (no-ff for traceability)
git switch integration/2025-w21
git merge --no-ff origin/feature/team-A-payment -m "Merge team-A-payment into integration/2025-w21"
git merge --no-ff origin/feature/team-B-checkout -m "Merge team-B-checkout into integration/2025-w21"
git push origin integration/2025-w21

# CI runs full regression against integration/2025-w21
# ... regression passes ...

# Cut release branch
git switch -c release/v2.5 integration/2025-w21
git push origin release/v2.5

# Tag the release commit (annotated, signed)
git tag -a -s v2.5.0 -m "Release 2.5.0 — payment + checkout features" HEAD
git push origin v2.5.0

// WHAT INTERVIEWERS LOOK FOR

A concrete model with named branches and clear purposes, not just buzzwords. Integration branch for cross-team regression. Annotated/signed tags for release traceability. CI gate definitions at each stage. Feature flags decoupling merge from activation.

// 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 would you handle environments (dev/staging/prod) for different test suite tiers?

CI/CD & DevOps

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

Git