Chapter 4.2 — Git Flow Strategy☕ 15 min read

Git Flow Strategy

5 branch types: main, develop, feature, release, hotfix. Feature develop mein jaata hai, release main aur dono mein jaata hai. --no-ff yaad rakho!

01Git Flow: The 5 Branch Types

Git Flow was created by Vincent Driessen in 2010. It is a structured branching model designed for projects with scheduled releases. Think of it as a traditional Indian wedding — bahut ceremony, bahut structure, sab kuch planned.

The model defines 5 branch types, each with a specific role and strict rules about where it comes from and where it merges to:

main — Production-ready code. Only receives merges from release or hotfix branches. This is the mandap — the sacred stage.
develop — Integration branch where all features come together. The next release is built here. This is the mehfil — where everyone gathers.
feature/* — Branched from develop, merged back to develop. Each feature gets its own branch. These are the mehman — guests who come and go.
release/* — Branched from develop, merged to BOTH main and develop. This is the baraat — the procession that takes develop to main.
hotfix/* — Branched from main, merged to BOTH main and develop. This is the doctor — called only in emergencies.

The key insight: main only receives code through release or hotfix merges. Feature branches never touch main directly.

# The 5 branch types:
# main:      production code
# develop:   integration / next release
# feature/*: new features
# release/*: release preparation
# hotfix/*:  production emergency fixes

# Initialize Git Flow (manual setup)
git checkout -b develop main
git push -u origin develop

Git Flow is a strategy, not a Git feature. Git has no built-in concept of Git Flow. It is a set of conventions about how to use branches. You can install the git-flow extension for convenience, but it just runs standard Git commands under the hood.

02Feature Branch Flow

The feature branch is where actual development work happens. Every new feature, bug fix (non-urgent), or experiment gets its own branch from develop.

The flow is simple:

Start from develop: git checkout -b feature/login develop
Work on the feature — commit regularly with meaningful messages.
When done, merge back to develop: git checkout develop && git merge --no-ff feature/login
Delete the feature branch after merging.

Why --no-ff? The --no-ff flag prevents fast-forward merges. Even if develop has not moved since you branched, Git creates a merge commit. This preserves the branch topology — you can see in the log exactly which commits belonged to the feature.

Without --no-ff, the feature commits would appear as if they were made directly on develop. The history becomes a flat line — no way to tell where a feature started or ended.

Never merge features directly to main! In Git Flow, main only receives code through release or hotfix branches.

# Feature flow
git checkout develop
git checkout -b feature/login

# Work on feature...
echo "login code" > login.js
git add . && git commit -m "feat: add login"

# Complete feature, merge to develop
git checkout develop
git merge --no-ff feature/login
git branch -d feature/login

💡 Pro Tip: Name your feature branches with prefixes like feature/, bugfix/, or chore/. This makes the branch purpose obvious. Examples: feature/user-auth, bugfix/checkout-crash, chore/update-deps.

03Release Branch Flow

When develop has accumulated enough features for a release, you create a release branch. This starts the release preparation phase.

The release branch:

Is branched from develop: git checkout -b release/1.2 develop
Allows only bug fixes, documentation, and version bumps — NO new features.
Is tested thoroughly before merging.
Merges to BOTH main and develop when ready.

Why merge to both? The release branch may contain bug fixes discovered during testing. If you only merge to main, those fixes are lost from develop. The next release from develop would re-introduce those bugs!

Tagging: Always tag the merge commit on main: git tag -a v1.2.0 -m "Release 1.2.0". Tags mark exact release points — you can always check out a specific production version.

While the release branch is being prepared, new features can continue on develop. They will be part of the NEXT release, not this one.

# Release flow
git checkout -b release/1.2 develop

# Bug fixes and version bumps only
echo "version 1.2.0" > version.txt
git add . && git commit -m "chore: bump version to 1.2.0"

# Ready for release!
# Merge to main
git checkout main
git merge --no-ff release/1.2
git tag -a v1.2.0 -m "Release 1.2.0"

# Also merge back to develop (so develop gets the bug fixes)
git checkout develop
git merge --no-ff release/1.2

# Cleanup
git branch -d release/1.2

The release branch is a buffer zone. It isolates release preparation from ongoing development. While testers verify the release branch, developers can keep pushing features to develop for the next cycle. Without release branches, you would need to freeze develop entirely during testing.

04Hotfix Branch Flow

Production is broken! The website is down, payments are failing, security vulnerability found — this is a hotfix emergency.

Hotfix branches are the only branches that branch directly from main (other than the initial develop branch setup):

Branch from main: git checkout -b hotfix/fix-payment main
Fix the critical bug and commit.
Merge to main with a tag: git checkout main && git merge --no-ff hotfix/fix-payment && git tag -a v1.2.1
Also merge to develop so the fix is not lost in the next release.

Special case: If a release branch currently exists, merge the hotfix to the release branch instead of develop. The release branch will eventually merge to develop anyway.

Hotfixes are the only branches that should ever touch main directly (via merge). Feature branches and develop never merge to main — only release and hotfix do.

# Hotfix flow - PRODUCTION EMERGENCY!
git checkout -b hotfix/security-patch main

# Fix the bug
echo "security fix" > security.js
git add . && git commit -m "fix: patch security vulnerability"

# Merge to main
git checkout main
git merge --no-ff hotfix/security-patch
git tag -a v1.2.1 -m "Hotfix 1.2.1"

# Also merge to develop
git checkout develop
git merge --no-ff hotfix/security-patch

# Cleanup
git branch -d hotfix/security-patch

💡 Pro Tip: Hotfix branches should be small and focused. Fix ONLY the critical issue. Do not bundle "while I am here" changes into a hotfix. Every extra line changed in a hotfix is a risk to production. Ship the minimal fix, then address improvements in a feature branch.

05Git Flow: Pros, Cons & When to Use

Git Flow is not a silver bullet. It was designed for a specific type of project and workflow.

Pros:

Organized history — each branch type has a clear purpose, and --no-ff preserves feature boundaries.
Clear release cycle — release branches make it obvious what is being shipped and when.
Safe main branch — main only receives code through release or hotfix, never raw features.
Audit trail — tags and merge commits create a clear history of what went to production and when.

Cons:

Complex — 5 branch types, strict merge rules, easy to make mistakes.
Slow — features must go through develop then release before reaching production.
Overkill for small teams — a 3-person team does not need this ceremony.
CI/CD teams do not need it — continuous deployment makes release branches unnecessary.

Use Git Flow when: scheduled releases (monthly/quarterly), large team (10+ developers), regulated industries, needs audit trail.

Do not use Git Flow when: continuous deployment, small team (2-5 developers), fast iteration, daily deploys.

# Good fit for Git Flow:
# - Enterprise software with quarterly releases
# - Teams of 10+ developers
# - Regulated industries (medical, finance)
# - Needs clear release history and audit trail

# Bad fit for Git Flow:
# - SaaS with continuous deployment
# - Small teams (2-5 developers)
# - Fast iteration, daily deploys
# - Mobile apps with fast release cycles

# Alternative: GitHub Flow (simpler)
# main + feature branches with PRs. No develop, no release branches.

Git Flow was designed for the era of scheduled software releases, not continuous deployment. Many teams adopt Git Flow because it is famous, then regret the overhead. In interviews, knowing when NOT to use Git Flow is more valuable than knowing the branching rules. Always match your strategy to your deployment cadence.

Lo kar liya — Key Points:

✅ Git Flow has 5 branch types: main (production), develop (integration), feature (new work), release (prep), hotfix (emergency)
✅ Feature branches merge into develop, never directly to main
✅ Release branches merge to BOTH main (with a tag) and develop (to keep bug fixes)
✅ Hotfix branches merge to BOTH main (with a tag) and develop
✅ Use --no-ff in Git Flow to preserve branch topology and make history readable
✅ Git Flow is best for scheduled releases and large teams; overkill for continuous deployment

Previous4.1 — Branches Kya Hoti Hain 📋 All Chapters Next Chapter4.3 — Trunk Based Development →