Introduction
A branching strategy defines how a team creates, names, and merges branches to manage parallel work, releases, and hotfixes. Choosing the right strategy affects release cadence, code stability, and how much overhead the team carries.
Cricket analogy: A branching strategy is like how a franchise manages its player pool across formats — some keep separate squads for Tests, ODIs, and T20s (like feature branches) while others rotate one core group, and the choice affects selection speed, form consistency, and management overhead.
Explanation
Git Flow uses a long-lived develop branch alongside main, with dedicated feature/* branches created off develop, release/* branches cut from develop to stabilize a version before shipping, and hotfix/* branches created directly off main to patch production urgently. It is well suited to projects with scheduled releases and versioned software. GitHub Flow, by contrast, keeps main always deployable: developers branch directly off main for any change, open a pull request, get it reviewed, and merge back into main, which is then deployed — there is no separate develop branch. Trunk-based development pushes this further, with developers committing small, frequent changes directly to main (trunk) or very short-lived branches, often behind feature flags, to keep everyone continuously integrated.
Cricket analogy: Git Flow is like keeping a full 'development squad' (develop) for trialing players (feature branches), a 'conditioning camp' (release branch) before a big match, and an emergency injury call-up straight to the main squad (hotfix); GitHub Flow always fields its best eleven (main), swapping in a trialist after a quick assessment (PR); trunk-based makes tiny lineup tweaks every match day behind low-stakes testing (feature flags).
Example
# Git Flow: create a feature branch from develop
git checkout develop
git checkout -b feature/checkout-redesign
# ...work, commit...
git checkout develop
git merge --no-ff feature/checkout-redesign
# Git Flow: cut a release branch to stabilize
git checkout -b release/2.4.0 develop
# Git Flow: hotfix branch off main for an urgent production bug
git checkout -b hotfix/2.3.1 main
# GitHub Flow: branch off main, PR, merge, deploy
git checkout main
git checkout -b fix/login-timeout
# ...work, push, open PR, review, merge to main, deploy...Analysis
Git Flow's structure is valuable when a product ships versioned releases on a schedule and needs a stable place (develop) to integrate features before a release freeze, but the extra branches add process overhead and can slow down continuous delivery. GitHub Flow and trunk-based development trade that structure for speed: with a single source of truth (main) and frequent small merges, teams reduce merge conflicts and get changes to production faster, but they depend heavily on strong CI, automated testing, and feature flags to keep main safe to deploy at any time. The right choice depends on release cadence — infrequent versioned releases favor Git Flow, while continuous deployment favors trunk-based or GitHub Flow.
Cricket analogy: Git Flow suits a team prepping for a scheduled ICC tournament with a long training camp to stabilize the squad, but the camp adds overhead; GitHub Flow and trunk-based suit a franchise playing back-to-back T20 league matches, relying on fitness testing (like CI) to keep the eleven always match-ready — the choice depends on one big tournament versus a packed league season.
Key Takeaways
- Git Flow uses develop, feature, release, and hotfix branches for scheduled, versioned releases.
- GitHub Flow keeps main always deployable, branching directly off main for every change via pull request.
- Trunk-based development favors small, frequent commits to main, often behind feature flags.
- Git Flow adds structure and overhead; GitHub Flow/trunk-based favor speed but need strong CI.
- Choose a strategy based on release cadence and team maturity with automated testing.
Practice what you learned
1. In Git Flow, which branch is a hotfix branch typically created from?
2. What is a defining characteristic of GitHub Flow?
3. Trunk-based development relies most heavily on which practice to keep main safe to deploy at any time?
4. Which branching strategy is generally best suited to a product shipping scheduled, versioned releases (e.g., v2.4.0)?
Was this page helpful?
You May Also Like
Git Fundamentals
Learn Git's three-tree model and the core commands for tracking, staging, and committing changes.
CI/CD Basics
Understand Continuous Integration, Continuous Delivery, and Continuous Deployment, and how a typical pipeline works.
Code Review Best Practices
Practical techniques for writing reviewable pull requests and giving constructive, effective code review feedback.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics