Git Branching Strategies: Git Flow vs GitHub Flow vs Trunk-Based Development

Every team needs agreed rules for branches. This lesson explains the three most popular Git branching strategies, GitHub Flow, Git Flow and trunk-based development, with diagrams, pros and cons, a comparison table and guidance on choosing.

---

🌳 Why You Need a Branching Strategy

When one person uses Git, almost anything works. When ten people commit every day, the team needs agreed rules: Which branches exist? Where do new features start? What gets deployed? How are urgent fixes released? That set of rules is a branching strategy (or Git workflow).

This lesson compares the three most popular strategies and shows how to choose. You should be comfortable with branches, merging and pull requests.

---

🚀 GitHub Flow

The simplest strategy, created by GitHub:

main ───●───────●───────────●──────────●──── (always deployable)
         \     /             \        /
          ●───●  feature/a    ●──●───●  feature/b
              PR + review         PR + review

Rules:

1. main is always deployable.
2. For any change, create a descriptive branch from main.
3. Commit and push regularly; open a pull request early.
4. Review, discuss and let CI run.
5. Merge to main and deploy (often automatically).

Pros	Cons
Very simple; few branches	Needs strong CI and automated tests
Fast feedback, continuous delivery	Not ideal for supporting several released versions at once

Best for: web apps and SaaS with continuous deployment.

---

🏗️ Git Flow

A structured model with long-lived branches, introduced by Vincent Driessen in 2010:

Branch	Lifetime	Purpose
main	Permanent	Production releases only, each tagged (v2.4.0)
develop	Permanent	Integration branch for the next release
feature/*	Temporary	New features, branched from and merged back into develop
release/*	Temporary	Stabilise a release (bug fixes, versioning); merged into main and develop
hotfix/*	Temporary	Urgent production fixes from main; merged into main and develop

main     ●──────────────────────●────────●   (v2.4.0)   (v2.4.1)
          \                    / \      /
release    \        ●───●─────●   \    /
            \      /               hotfix
develop      ●──●──●───●───●──────────●──●
              \   /     \  /
feature        ●─●       ●●

Pros	Cons
Clear separation of development and production	Many branches and merges; more overhead
Supports scheduled releases and multiple versions	Slower feedback; long-lived branches cause bigger conflicts
Natural fit for QA phases on release branches	Considered heavy for continuous delivery

Best for: products with versioned, scheduled releases (mobile apps, installed software, regulated environments).

---

⚡ Trunk-Based Development

Everyone integrates into one main branch (the trunk) at least daily:

• Very short-lived branches (hours, at most a day or two), or direct commits to main for small teams.
• Unfinished features are hidden behind feature flags instead of long branches.
• Heavy reliance on automated tests that run on every change.
• Releases are cut from main (sometimes via short-lived release branches).

Pros	Cons
Minimal merge conflicts; continuous integration in the truest sense	Requires excellent test automation and discipline
Fastest delivery	Feature flags add complexity
Used by many high-performing engineering organisations	Harder for beginners and teams with weak CI

Best for: experienced teams with mature CI/CD and strong automated test suites.

---

⚖️ Side-by-Side Comparison

	GitHub Flow	Git Flow	Trunk-Based
Long-lived branches	main	main + develop	main (trunk)
Feature branch lifetime	Days	Days to weeks	Hours to a day
Release style	Continuous	Scheduled versions	Continuous
Complexity	Low	High	Low process, high engineering discipline
Hotfixes	Normal PR to main	hotfix/* branch	Fix on trunk, cherry-pick if needed
Dependence on test automation	High	Medium	Very high

---

🧭 How to Choose

• Small team, web app, deploys often: GitHub Flow.
• Versioned product, multiple supported releases, formal QA phase: Git Flow (or a lighter variant).
• Mature DevOps team, strong CI, feature flags: trunk-based development.
• Several environments (dev, QA, staging, prod): many teams add environment branches or, better, promote the same build through environments with a deployment pipeline (deploy with GitHub Actions).

---

🧪 What It Means for Testers

Strategy	Where testers test
GitHub Flow	On each PR (preview environments, CI tests) and continuously on main
Git Flow	Feature testing on develop; regression on release/* before merging to main
Trunk-based	Mostly automated on every commit; exploratory testing behind feature flags

Automated tests running on every pull request (for example Playwright in GitHub Actions) are essential for all three.

---

📝 Assignment

1. In git-practice, simulate GitHub Flow: two feature branches, two PRs, merge both to main.
2. Simulate Git Flow: create develop, a feature/* branch merged into develop, a release/0.3.0 branch merged into main and develop, and a tag v0.3.0.
3. Simulate a hotfix in Git Flow and merge it into both main and develop.
4. Write a one-page branching guide for a team of five testers and developers who deploy weekly. Which strategy would you choose and why?

---

❓ FAQ

🤔 What is a Git branching strategy?

An agreed set of rules for how a team creates, names, merges and releases branches, such as GitHub Flow, Git Flow or trunk-based development.

🤔 What is the difference between Git Flow and GitHub Flow?

Git Flow uses long-lived main and develop branches plus feature, release and hotfix branches for scheduled releases. GitHub Flow uses only main plus short-lived feature branches merged through pull requests and deployed continuously.

🤔 What is trunk-based development?

A strategy where everyone integrates small changes into one main branch at least daily, using very short-lived branches and feature flags.

🤔 Which branching strategy is best?

It depends on your release style and test automation. GitHub Flow suits most web teams; Git Flow suits versioned releases; trunk-based suits mature teams with strong CI.

🤔 Is Git Flow still used?

Yes, especially for versioned products, but many teams doing continuous delivery have moved to GitHub Flow or trunk-based development.

---

🎯 Next Steps

• ✍️ Commit Messages and Conventional Commits
• 🧑‍💻 Git and GitHub in VS Code
• 📘 Git and GitHub Tutorial: full course