Git Workflows — Git Flow, GitHub Flow, Trunk-Based

Module 04 60 min

---

Section Objectives

• Understand and compare the main Git workflows
• Implement Git Flow for a project with versioned releases
• Apply GitHub Flow for continuous deployment
• Understand trunk-based development and feature flags

---

Why Have a Workflow?

A Git workflow defines:

• Which branches exist and what they represent
• Who can push where
• How code moves from development to production
• When to create tags and releases

Without a workflow: chaos. With a workflow: clarity and efficiency.

---

1. Git Flow

Git Flow (Vincent Driessen, 2010) is a rigorous workflow suited for projects with versioned releases.

Git Flow Branches

Branch	Lifespan	Role
main	Permanent	Production — only tagged releases
develop	Permanent	Integration — next release in progress
feature/*	Temporary	One feature per branch
release/*	Temporary	Release preparation (bug fix only)
hotfix/*	Temporary	Emergency production fix

Git Flow Commands

# Initialize git-flow (install first: brew install git-flow)
git flow init

# Start a feature
git flow feature start user-login
# Equivalent to: git switch -c feature/user-login develop

# Finish a feature
git flow feature finish user-login
# Equivalent to:
# git switch develop
# git merge --no-ff feature/user-login
# git branch -d feature/user-login

# Start a release
git flow release start v1.0.0
# Equivalent to: git switch -c release/v1.0.0 develop

# Finish a release
git flow release finish v1.0.0
# Merges into main AND develop, creates tag

# Start a hotfix
git flow hotfix start v1.0.1
# Equivalent to: git switch -c hotfix/v1.0.1 main

# Finish a hotfix
git flow hotfix finish v1.0.1
# Merges into main AND develop, creates tag

Git Flow: When to Use?

✅ Ideal for:

• Software with numbered versions (v1.0, v2.3...)
• Multiple versions in parallel production
• Planned release cycles
• Large teams with strict processes

❌ Not ideal for:

• Continuous deployment (deploys several times per day)
• Small teams or solo projects
• Early-stage startups iterating fast

---

2. GitHub Flow

GitHub Flow is a much simpler workflow, developed by GitHub for their own workflow.

GitHub Flow Rules

1. main is always deployable
2. All work is done on a feature branch
3. Feature branches are pushed to GitHub regularly
4. When ready, open a Pull Request
5. Deploy from the PR (deploy to staging for testing)
6. Once validated, merge to main

# GitHub Flow in practice
git switch main
git pull

# 1. Create a branch
git switch -c feature/dark-mode

# 2. Work
git commit -m "feat: add dark mode toggle"
git commit -m "feat: persist dark mode in localStorage"

# 3. Push regularly
git push -u origin feature/dark-mode

# 4. Open PR
gh pr create --title "feat: add dark mode"

# 5. Deploy from PR for testing (depends on CI/CD)

# 6. After PR approved and validated
gh pr merge --squash --delete-branch

# 7. Deploy main to production
git switch main
git pull

GitHub Flow: When to Use?

✅ Ideal for:

• Continuous deployment
• SaaS web apps
• Small to medium teams
• Projects that deploy daily

---

3. Trunk-Based Development

The most modern approach, used by Google, Facebook, and many high-performing tech companies.

Principles

Principle	Description
One trunk	Only one main long-lived branch
Frequent small commits	Multiple times per day
Short branches	< 1 day before merge
Feature flags	Deploy code before activating features
Comprehensive CI	Every commit is tested automatically

Feature Flags with Trunk-Based Dev

# config/features.py
FEATURE_FLAGS = {
    "new_checkout": os.getenv("FF_NEW_CHECKOUT", "false") == "true",
    "dark_mode": os.getenv("FF_DARK_MODE", "false") == "true",
    "ai_recommendations": os.getenv("FF_AI_RECOMMENDATIONS", "false") == "true",
}

# In your code
if FEATURE_FLAGS["new_checkout"]:
    return new_checkout_flow(cart)
else:
    return legacy_checkout_flow(cart)

# Deploy to production with flag disabled
git push main
# Code is live but new_checkout feature is OFF

# Gradually enable for users
# FF_NEW_CHECKOUT=true for 5% of users
# FF_NEW_CHECKOUT=true for 50% of users
# FF_NEW_CHECKOUT=true for all users
# Remove old code when rollout complete

TBD: When to Use?

✅ Ideal for:

• DevOps mature teams (automated testing, CI/CD)
• Multiple deploys per day
• Google/Netflix/Amazon style teams

❌ Not ideal for:

• Teams without solid automated tests
• Projects without CI/CD infrastructure
• Junior teams needing protection

---

Comparison

Criterion	Git Flow	GitHub Flow	Trunk-Based
Complexity	High	Low	Medium
Branch lifespan	Long	Short	Very short
Deploy frequency	Low (scheduled)	High (continuous)	Very high
Team size	Large	Small to medium	Any
Best suited for	Versioned software	SaaS/web apps	High-performance DevOps
Learning curve	Steep	Gentle	Moderate

---

Summary

Workflow	Core Idea
Git Flow	Two main branches (main + develop), multiple supporting types
GitHub Flow	main always deployable, short feature branches, deploy via PR
Trunk-Based Dev	Everyone commits frequently to main, feature flags control activation

---

Next Steps

• Hands-on Lab TP5 — Apply a workflow on a team project
• Module 05 - Advanced Git