Branching Strategies — GitFlow, Trunk-Based, Feature Branches

You now know how to create a branch and merge it. The next question is when and how often — and that's a team decision, not a technical one. A branching strategy is your team's written agreement about which branches exist, what each one is for, and how work flows between them. Three strategies dominate the industry: Feature Branch, GitFlow, and Trunk-Based Development. This lesson explains each, contrasts them through a QA lens, and gives you a way to recognise which one your team is using on day one.

Why a strategy matters

A team without a strategy invents one accidentally — usually a bad one. Two developers branch from different places, three branches sit half-merged for a month, the test team can never figure out which branch is "the one to test against." A written strategy answers four questions:

1. Where do new branches come from?
2. Where do they merge back to?
3. What goes on main vs other long-lived branches?
4. When do tests run, and against which branch?

The wrong choice slows a team down. The right one fades into the background.

Strategy 1 — Feature Branch Workflow

The simplest strategy, and the most common in test automation projects:

• main is always stable.
• For every piece of work, create a feature branch off main.
• Push the branch, open a pull request, get reviewed, merge back to main.
• Delete the branch.

That's it. There's no develop, no release, no parallel long-lived branches. Every branch's life is hours to a few days; every merge goes back to the same place it came from.

git switch main
git pull
git switch -c feature/checkout-regression-tests
# ...work, commit, push...
# ...open PR, review, merge on GitHub...
git switch main && git pull && git branch -d feature/checkout-regression-tests

This is the workflow most QA engineers will join. It's the safest place to start for anyone new to Git, and it scales to teams of dozens without falling over.

Strategy 2 — GitFlow

A more structured strategy, born in the era of scheduled releases (mobile apps, enterprise software, on-prem deployments). GitFlow uses two long-lived branches and three short-lived branch types:

• main — exact copy of what's in production. Every commit on main is a release.
• develop — the integration branch. Features merge here first.
• feature/* — branches off develop, merges back to develop.
• release/* — branches off develop when prepping a release. Bug fixes only. Merges to both main (the release) and develop (so develop has the fixes).
• hotfix/* — branches off main for an urgent production fix. Merges to both main and develop.

It's heavier — more branches, more merges, more rules. The payoff is clarity for projects with formal release cycles: at any moment you can point at a branch and say exactly what stage it represents. QA testing typically happens on develop (continuous integration testing) and release/* (release-candidate sign-off testing).

GitFlow is overkill for most modern web teams that ship continuously, but it's still the right answer for some enterprise QA environments. If your team has a "release manager," a "hardening week," or a "release candidate phase," they're probably running GitFlow even if nobody calls it that.

Strategy 3 — Trunk-Based Development

The opposite extreme. Everyone commits to main (the "trunk") frequently — hours, not days. Branches exist but are short — maybe one work session before merging back. Unfinished work hides behind feature flags so you can ship the code without exposing the feature.

The argument: long branches accumulate merge debt, hide integration problems, and decay. Frequent small merges expose problems early, when they're cheapest. To do this safely you need:

• A solid automated test suite that runs in seconds on every commit.
• Feature flags to toggle in-progress work off in production.
• Strong CI/CD (every commit deploys to staging or canary; failures alarm fast).

Trunk-based is the strategy of teams shipping multiple times a day — Google, Facebook, Netflix-style cadence. As a QA engineer on a trunk-based team, your work shifts: less "test this branch end-to-end before merge," more "make sure the test suite catches regressions in real time, because real time is when they ship."

How testing changes per strategy

The strategy decides where you spend your day. On a feature-branch team you spend it reviewing PRs. On a GitFlow team you spend it on the release branch. On a trunk-based team you spend it on main watching CI dashboards.

A QA day in each strategy

Feature Branch. Morning: pull main, switch to a developer's branch (feature/payment-gateway), run the suite locally, find a bug, comment on the PR. Afternoon: branch off main as test/payment-edge-cases, write three tests, push, open your own PR.

GitFlow. Morning: switch to develop, pull, run the suite. Help the dev team integrate the day's feature merges. Afternoon: jump to release/2.7 for sign-off testing — exploratory + regression — and triage anything found into hotfix-eligible vs next-release.

Trunk-Based. Morning: monitor main build status. A test failed? Investigate within minutes — was it the merge, was it flake, was it real? Afternoon: write a regression test for the bug a customer hit yesterday and merge it to main today so future merges can't reintroduce it.

The three strategies side by side

How to tell which strategy your team uses on day one

Three quick checks:

1. Run git branch -a. Multiple long-lived branches like develop, release/2.7, release/2.8? GitFlow. Just main plus short feature branches? Feature Branch or Trunk-Based.
2. Look at PR cadence. A few PRs per week, each large? Feature Branch. Tens of PRs per day, each tiny, all merging to main? Trunk-Based.
3. Ask: "Where do bug fixes go?" "Branch off main and PR back" → Feature Branch. "Branch off develop, merge to develop, then cherry-pick to release/*" → GitFlow. "Commit to main and roll forward" → Trunk-Based.

Which one should you start with?

If you're choosing for a small QA team or your own automation repo, start with Feature Branch. It's the simplest, requires no special tooling, and is the gateway most QA engineers walk through into Git fluency. Adopt GitFlow only if your release process genuinely requires it; adopt Trunk-Based only when your test automation and CI are mature enough to catch regressions in seconds, not hours.

⚠️ Common mistakes

• Cargo-culting GitFlow. Teams sometimes adopt GitFlow because it sounds "professional," then discover they don't actually have releases — they ship continuously. Result: ceremony without value, and develop slowly diverges from main because nobody enforces it. Match the strategy to the release pattern, not the other way round.
• Calling everything "feature branch" while doing GitFlow. "We do feature branches" can mean radically different things. Always confirm: branch from where? Merge to where? If develop exists in git branch -a, you're on GitFlow regardless of vocabulary.
• Mixing strategies on the same repo. Some commits land directly on main, others go through PRs, others through release/*. The result is no strategy at all. Pick one and write it down — even a one-page README at the repo root saves enormous confusion for new joiners.

🎯 Practice task

Identify and document your team's strategy. 20 minutes.

1. In a real repo (your team's, or a public one like https://github.com/cypress-io/cypress), run git branch -a | head -30. Note the long-lived branches that aren't main.
2. Open the GitHub Pull Requests tab. Look at the last 20 merged PRs. What branch did they target? main? develop? Multiple targets?
3. From those two signals, classify the strategy as Feature Branch, GitFlow, or Trunk-Based. Write one sentence explaining your reasoning.
4. Read the CI/CD for testers cheat sheet and find the section on test triggers. Map it to your strategy: where does the suite run, and at what trigger?
5. Stretch: if your team's strategy isn't written down anywhere, draft a five-bullet README section. Where do branches come from, where do they merge to, who reviews, when do tests run, when do branches get deleted. Share it in standup tomorrow.

That closes Chapter 2. You can now branch, switch, merge, resolve conflicts, and read a team's strategy at a glance. Chapter 3 takes branches public — connecting your local Git to GitHub and the wider world of remote collaboration.