Branching Strategies

Why Branching Strategy Matters for QA

The branching strategy your team uses determines how you manage test branches, when you run which tests, and how releases map to test results. Understanding the strategy is not optional -- it directly shapes your test execution plan.

The Three Main Strategies

GitFlow in Detail

GitFlow uses two long-lived branches (main and develop) plus short-lived branches for features, releases, and hotfixes.

main ──────────────●───────────────────●──────── (production releases)
                   ↑                   ↑
release/2.3 ──────●   release/2.4 ────●
                   ↑                   ↑
develop ───●──●──●─┘──●──●──●──●──●───┘──●──── (integration branch)
           ↑  ↑  ↑    ↑  ↑  ↑  ↑  ↑      ↑
           feature branches (short-lived)

QA Implications for GitFlow

• Test on develop: Every feature merged to develop should trigger regression tests
• Test again on release/*: The release branch is for stabilization. Only bug fixes go here, and each fix needs testing
• Double testing burden: You may test a feature on develop and then test the same feature again on the release branch
• Hotfix testing: Hotfixes branch from main, get tested, merge to both main and develop
• Environment mapping: develop maps to a dev/integration environment, release/* maps to staging, main maps to production

When to advocate for GitFlow:

• Your product has scheduled releases (quarterly, monthly)
• Multiple versions are supported simultaneously (v2.3 and v2.4 both in production)
• Regulatory requirements demand a stabilization phase before release

GitHub Flow in Detail

GitHub Flow uses a single main branch. All work happens on feature branches that merge via pull requests.

main ──────●──●──●──●──●──●──●──●──●──── (always deployable)
           ↑  ↑  ↑  ↑  ↑  ↑  ↑  ↑  ↑
           PRs from feature branches

QA Implications for GitHub Flow

• Test on PR: Every pull request triggers the full test suite. This is your primary quality gate.
• Main is always deployable: If tests pass on the PR and the PR is merged, main should be safe to deploy at any time
• No stabilization phase: There is no release branch. If something is broken on main, fix it with another PR.
• Simpler environment mapping: Feature branches deploy to preview environments, main deploys to production

When to advocate for GitHub Flow:

• Your team does continuous deployment (deploy multiple times per day)
• You have a single version in production
• Your CI pipeline is fast and reliable enough to gate PRs effectively

Trunk-Based Development in Detail

Trunk-based development takes GitHub Flow to its extreme. Feature branches live less than a day. Developers commit to main frequently, often multiple times per day.

main ──●●●●●●●●●●●●●●●●●●●●●● (continuous stream of small commits)
       ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
       Very short-lived branches (hours, not days)

QA Implications for Trunk-Based Development

• Every commit must pass all tests: There is no stabilization period. The pipeline must be fast and reliable.
• Feature flags replace feature branches: Incomplete features are deployed behind flags, not on separate branches
• Testing shifts left dramatically: QA reviews requirements and writes tests before development starts, because there is no time to catch up later
• Flaky tests are existential threats: A flaky test that blocks main blocks the entire team. Fix flaky tests immediately.

When trunk-based development works:

• The team has high test automation maturity (>90% of tests automated)
• CI pipeline completes in under 10 minutes
• Feature flags are available and well-managed
• The team has strong code review discipline

Adapting Your Test Plan to the Strategy

Transitioning Between Strategies

Teams often start with GitFlow and migrate toward GitHub Flow or trunk-based development as their automation matures. If your team is considering a transition, here is what QA needs to prepare:

Moving from GitFlow to GitHub Flow

1. Speed up the pipeline: GitHub Flow relies on PR checks as the primary gate. If your pipeline takes 40 minutes, PRs will be painful.
2. Eliminate the release branch test phase: All testing must happen on the PR. Any tests that only ran on the release branch must move to the PR pipeline.
3. Improve test reliability: In GitFlow, a flaky test on the release branch might be tolerated. In GitHub Flow, a flaky test blocks every PR.

Moving from GitHub Flow to Trunk-Based

1. Implement feature flags: You need a way to deploy incomplete features safely.
2. Reduce pipeline time to under 10 minutes: Developers cannot wait 20 minutes for every small commit.
3. Achieve near-zero flaky test rate: Every test failure on main blocks the team.
4. Shift QA earlier: QA must participate in design and requirements, not wait for code.

Hands-On Exercise

1. Identify which branching strategy your current team uses.
2. Map out when each type of test runs in your workflow. Are there gaps?
3. If your team uses GitFlow, identify tests that run twice (on develop and on release). Could you eliminate the duplication?
4. If your team uses GitHub Flow, measure your PR pipeline time. Is it under 15 minutes?
5. Propose one improvement to your team's test execution plan based on the branching strategy.