Skip to content

Branching Strategies: Git Flow, GitHub Flow & Trunk-Based Development

DodaTech Updated 2026-06-22 5 min read

In this tutorial, you'll learn about Branching Strategies: Git Flow, Github Flow & Trunk. We cover key concepts, practical examples, and best practices.

Branching strategies define rules for creating and merging branches in Git, determining how your team ships features, handles hotfixes, and manages releases.

In this tutorial, you'll learn the three major Git branching strategies used by professional teams worldwide. Choosing the right branching strategy determines how smoothly your team ships features, handles hotfixes, and manages releases — a bad choice creates merge hell while a good one makes deployment routine. By the end, you'll know which workflow fits your project size, release cadence, and team structure.

flowchart TD
  subgraph GitFlow
    A[main] --> B[develop]
    B --> C[feature]
    C --> B
    B --> A
    A --> D[hotfix]
    D --> A
    D --> B
  end

Git Flow: The Classic Approach

Git Flow uses two permanent branches — main and develop — plus temporary branches for features, releases, and hotfixes. It was designed by Vincent Driessen in 2010 and works well for projects with scheduled releases.

# Create a feature branch
git checkout -b feature/user-auth develop

# Work and commit
echo "auth code" > auth.py
git add auth.py
git commit -m "Add user authentication"

# Merge back to develop
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

Expected output:

Merge made by the 'recursive' strategy.
 auth.py | 1 +
 1 file changed, 1 insertion(+)

Release branches prepare a new production release:

git checkout -b release/1.2.0 develop
# Bump version, fix last-minute bugs
git commit -m "Bump version to 1.2.0"
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0

GitHub Flow: Simpler and Faster

GitHub Flow uses a single main branch with short-lived feature branches. Every feature branch becomes a pull request, undergoes review, and merges immediately to main for deployment. GitHub Flow is ideal for continuous deployment.

# Create feature branch from main
git checkout -b add-search

# Commit changes
echo "search feature" > search.py
git add search.py
git commit -m "Add search functionality"

# Push and create PR
git push -u origin add-search
# Open pull request on GitHub, get review
# Merge via GitHub UI, then delete remote branch

Trunk-Based Development

Trunk-based development has developers commit directly to main (the trunk) or use branches that last less than a day. Feature flags hide incomplete work. This strategy is used by teams like Google and Netflix for high-velocity deployment.

CI/CD pipelines are essential here — every commit triggers automated tests, and broken commits block the pipeline.

# Short-lived feature branch
git checkout -b add-header
echo "<header>Logo</header>" > header.html
git add header.html
git commit -m "Add site header"
git checkout main
git pull --rebase
git merge add-header
git push

Comparison Table

Feature Git Flow GitHub Flow Trunk-Based
Permanent branches 2 (main, develop) 1 (main) 1 (main)
Branch lifetime Days to weeks Hours to days Hours
Release cadence Scheduled Continuous Continuous
Hotfix support Dedicated branch Branch from main Feature flag
Team size 10+ 3-10 5-20+
Complexity High Low Medium
CI/CD integration Optional Required Required

When to Use Each Strategy

Git Flow suits projects with versioned releases, like mobile apps or libraries. GitHub Flow works for web applications deployed multiple times daily. Trunk-based development fits mature DevOps teams with strong automated testing and feature flag infrastructure.

Common Errors

Error Cause Fix
merge conflict on develop Long-lived feature branches Rebase frequently or use shorter branches
not fast-forward rejection Non-linear history Use git merge --ff-only or rebase
Detached HEAD after checkout Wrong branch name Use git switch -c to create branches
Forgot to delete branch Accumulated stale branches Use git branch -d after merging
Feature branch diverged No sync with base git rebase main before merging

Practice Questions

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

Git Flow uses two permanent branches (main and develop) with separate release and hotfix branches, making it suitable for scheduled releases. GitHub Flow uses one permanent branch (main) with short-lived feature branches that merge immediately via pull requests, ideal for continuous deployment.

When should I use trunk-based development?

Use trunk-based development when your team has strong CI/CD pipelines, automated testing, feature flags, and wants to deploy multiple times per day. It requires discipline — branches must be short-lived (under a day) and every commit must pass tests.

What is a hotfix branch in Git Flow?

A hotfix branch branches off main to fix a production bug urgently. After the fix, it merges into both main (with a version tag) and develop to ensure the fix is included in future releases.

Can I use GitHub Flow with mobile app releases?

Yes, but it's harder because mobile apps go through review processes. Many mobile teams use a modified GitHub Flow with release branches that undergo testing and app store submission before merging to main.

What are feature flags and why do they matter for trunk-based development?

Feature flags are conditional toggles that enable or disable features at runtime. They let developers merge incomplete features to main without affecting users. Feature flags eliminate the need for long-lived feature branches

Challenge

You join a team of 15 developers shipping a mobile app every two weeks. They currently use no branching strategy — everyone commits to main directly, causing frequent broken builds. Design a Git Flow branching model for them. Write the branch creation and merge commands for a typical feature cycle including a hotfix for a critical crash.

Real-World Task

Configure a GitHub repository with branch protection rules. Set up main as a protected branch requiring pull request reviews, status checks, and linear history. Create a feature branch, push it, open a pull request, and complete the merge workflow. Then optionally add a GitLab mirror with the same protection rules.


Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro