Git Workflows

Why Git Workflows Matter

Git gives you branches and merges, but a workflow decides how a team should use them.

This lesson compares three common models:

• GitFlow
• GitHub Flow
• Trunk-Based Development

Tip: Pick the lightest workflow that still fits your release process. More branches are only useful when they solve a real coordination problem.

GitFlow

GitFlow is a structured workflow designed for teams with planned releases.

Its long-lived branches are:

• main for production-ready history
• develop for ongoing integration

Supporting branches include:

• feature/*
• release/*
• hotfix/*

How GitFlow Works

A feature usually starts from develop:

git switch develop
git switch -c feature/add-audit-logs

When the feature is ready, it goes back into develop. Later, the team creates a release branch:

git switch develop
git switch -c release/2.4.0

For urgent production issues, a hotfix starts from main:

git switch main
git switch -c hotfix/fix-payment-timeout

The fix is merged into main and back into develop.

When GitFlow Fits

GitFlow works well when:

• releases are scheduled rather than continuous
• multiple supported versions exist
• teams want a dedicated release stabilization phase
• enterprise approval processes require more separation

The trade-off is more branch overhead.

GitHub Flow

GitHub Flow is a simpler PR-based model built around one main long-lived branch: main.

The usual steps are:

1. branch from main
2. make changes on a short-lived feature branch
3. open a pull request
4. review and test
5. merge back to main

Example:

git switch main
git pull origin main
git switch -c feature/update-runbook
git add .
git commit -m "docs: update deployment runbook"
git push -u origin feature/update-runbook

When GitHub Flow Fits

GitHub Flow is a strong choice when:

• the team is small or medium-sized
• pull requests are the main review mechanism
• main is kept releasable
• CI gives quick feedback

Note: GitHub Flow depends on a healthy main branch. Fast tests and code review are important because work merges there frequently.

Trunk-Based Development

Trunk-Based Development centers on one integration branch, usually main or trunk, and very short-lived branches.

Its main ideas are:

• integrate small changes often
• avoid long-lived branch drift
• keep merges frequent and low risk
• use feature flags for incomplete work

Example:

git switch main
git pull origin main
git switch -c feature/add-cache-metric
git commit -am "feat: add cache hit metric behind feature flag"
git push -u origin feature/add-cache-metric

Feature Flags in Trunk-Based Development

Because teams merge early, unfinished work is often hidden behind flags.

FEATURE_NEW_DASHBOARD=false

Feature flags separate deployment from release. Code can be merged and even deployed without being visible to users yet.

When Trunk-Based Development Fits

This workflow is often best for teams that:

• deploy frequently
• invest heavily in CI/CD
• want fewer merge conflicts
• can break large work into small safe increments

Its biggest challenge is discipline. Large long-running branches work against the model.

Choosing the Right Workflow

Small Team

A small team often starts best with GitHub Flow because it is simple.

Enterprise Team

A larger organization with formal release windows often prefers GitFlow.

CI/CD-Heavy Team

A team shipping many times per day often benefits most from Trunk-Based Development or a lightweight GitHub Flow variant, because both keep integration frequent.

Quick Comparison

What You Should Remember

GitFlow adds structure for releases and hotfixes, GitHub Flow keeps things simple around main and pull requests, and Trunk-Based Development pushes toward very fast integration with short-lived branches and feature flags. The best workflow is the one that matches your release cadence, team size, and automation maturity.

Test Your Understanding