Modern QA2026GitFlow in Detail
Log inJoin
3 / 11 · Book 17 · Branching Strategies← prev⊞ allnext →Get the book →

1.3GitFlow in Detail

GitFlow, introduced by Vincent Driessen in 2010, uses two long-lived branches (main and develop) plus short-lived branches for features, releases, and hotfixes. It is the most structured of the three strategies.

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

How GitFlow Works

  1. main always reflects the current production state. Every commit on main is a release.
  2. develop is the integration branch. All feature branches merge here.
  3. Feature branches branch from develop and merge back to develop when complete.
  4. Release branches (release/2.4) branch from develop when the team is ready to prepare a release. Only bug fixes go on the release branch -- no new features.
  5. Hotfix branches (hotfix/2.3.1) branch from main for urgent production fixes. They merge to both main and develop.

Implications for Testing

  • Test on develop: Every feature merged to develop should trigger regression tests.
  • Test again on release/*: The release branch is for stabilization. Each bug fix on the release branch 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 in isolation, then 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 Use 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.
  • Your team is large and needs the structure that multiple branches provide.

Pro Tip: GitFlow adds overhead. If you are deploying to production multiple times per day, GitFlow's release branches will slow you down. Use it when you genuinely need the stabilization phase, not because "that's how we've always done it."