Git Flow: The Professional Branching Workflow
Git Flow is a branching model for Git that defines a strict branch structure designed to manage projects of different sizes. Created by Vincent Driessen, Git Flow is particularly suited for projects with planned releases and teams working on multiple features in parallel.
🎯 What You'll Learn
- The branch structure in Git Flow (main, develop, feature, release, hotfix)
- How to manage features, releases, and hotfixes
- Naming conventions and best practices
- When to use Git Flow vs other workflows
The Main Branches
Git Flow uses two permanent branches that live for the entire project duration:
main (or master):
- Contains only production-ready code
- Every commit is an official release
- Tagged with version number (v1.0.0, v1.1.0, etc.)
- Never commit directly
develop:
- Integration branch for new features
- Contains the latest development state
- Feature branches start from here
- Base for the next releases
# Start a new project with Git Flow
git flow init
# Or manually:
git checkout -b develop main
Feature Branches
Feature branches are used to develop new features. They branch off from
develop and are merged back into develop when completed.
# Create a new feature branch
git flow feature start user-authentication
# Equivalent to:
# git checkout -b feature/user-authentication develop
# Work on the feature
git add .
git commit -m "feat: add login form"
git commit -m "feat: add JWT authentication"
git commit -m "test: add auth tests"
# Finish the feature (merge into develop and delete the branch)
git flow feature finish user-authentication
# Equivalent to:
# git checkout develop
# git merge --no-ff feature/user-authentication
# git branch -d feature/user-authentication
📝 Naming Convention for Features
feature/user-authenticationfeature/payment-integrationfeature/dark-mode- Use kebab-case
- Descriptive and concise names
Release Branches
Release branches support preparation of a new production release.
They allow minor bug fixes and preparation of metadata (version, build date) while the team
continues working on develop.
# Create release branch from develop when features are ready
git flow release start 1.2.0
# Equivalent to:
# git checkout -b release/1.2.0 develop
# Bug fixes and release preparation
git commit -m "chore: bump version to 1.2.0"
git commit -m "fix: correct typo in welcome message"
git commit -m "docs: update changelog"
# Finish the release (merge into main AND develop, tag on main)
git flow release finish 1.2.0
# Equivalent to:
# git checkout main
# git merge --no-ff release/1.2.0
# git tag -a v1.2.0
# git checkout develop
# git merge --no-ff release/1.2.0
# git branch -d release/1.2.0
# Push main, develop and tags
git push origin main develop --tags
⚙️ What to Do in Release Branch
- ✅ Minor bug fixes
- ✅ Update version number
- ✅ Prepare changelog
- ✅ Production build and final tests
- ❌ New features (go to develop)
Hotfix Branches
Hotfix branches are for fixing critical bugs in production that cannot
wait for the next release. They branch off from main and are merged into main
AND develop.
# Critical bug in production! (main is at v1.2.0)
git flow hotfix start 1.2.1
# Equivalent to:
# git checkout -b hotfix/1.2.1 main
# Fix the bug
git commit -m "fix: resolve critical payment bug"
# Finish the hotfix (merge into main and develop, tag on main)
git flow hotfix finish 1.2.1
# Equivalent to:
# git checkout main
# git merge --no-ff hotfix/1.2.1
# git tag -a v1.2.1
# git checkout develop
# git merge --no-ff hotfix/1.2.1
# git branch -d hotfix/1.2.1
# Immediate production deploy
git push origin main develop --tags
Complete Example: Development Cycle
Let's see a complete workflow from feature development to production:
# Initial setup
git flow init
# Creates branches: main, develop
# Sprint 1: Two developers work on different features
# Developer 1:
git flow feature start shopping-cart
# ... work ...
git commit -m "feat: add cart component"
git flow feature finish shopping-cart
# Developer 2:
git flow feature start user-profile
# ... work ...
git commit -m "feat: add profile page"
git flow feature finish user-profile
# Both features are now in develop
# Prepare release
git flow release start 1.0.0
git commit -m "chore: bump version to 1.0.0"
git commit -m "docs: update README"
git flow release finish 1.0.0
# main is now at v1.0.0, deployed to production
# Critical bug found in production!
git flow hotfix start 1.0.1
git commit -m "fix: cart total calculation error"
git flow hotfix finish 1.0.1
# main is now at v1.0.1, hotfix deployed
# Meanwhile, develop continues with new features
git checkout develop
git flow feature start payment-gateway
# ... development continues ...
Best Practices for Git Flow
✅ Do's
- Use
--no-fffor merges (preserves branch history) - Always tag releases on main
- Write descriptive commit messages (Conventional Commits)
- Test before finishing feature/release
- Push develop and main regularly
- Use Pull Requests for code review before finish
❌ Don'ts
- Don't commit directly to main or develop
- Don't keep feature branches open too long
- Don't include new features in release branches
- Don't forget to merge hotfix into develop
- Don't use Git Flow if you do continuous deployment
Naming Conventions
Clear naming conventions help the team understand the purpose of each branch:
# Feature branches
feature/user-authentication
feature/api-integration
feature/responsive-navbar
# Release branches
release/1.0.0
release/2.1.0
release/3.0.0-beta
# Hotfix branches
hotfix/1.0.1
hotfix/2.1.3
hotfix/security-patch-3.0.1
When to Use Git Flow
✅ Use Git Flow if:
- You have planned releases (not continuous deployment)
- You support multiple versions in production
- You have a large team with many parallel features
- You need a rigorous process for stability
❌ Avoid Git Flow if:
- You do continuous deployment (use GitHub Flow)
- You have a small team (< 3 people)
- The project is simple or a prototype
- Multiple deployments per day
Alternatives to Git Flow
Git Flow is not the only workflow. Here are the alternatives:
- GitHub Flow: Simpler, only main + feature branches, for continuous deployment
- GitLab Flow: Hybrid between Git Flow and GitHub Flow, with environment branches
- Trunk-Based Development: Everyone commits to main/trunk with feature flags
Tools for Git Flow
# macOS
brew install git-flow
# Linux (Ubuntu/Debian)
sudo apt-get install git-flow
# Windows (Git Bash)
# Download from: https://github.com/petervanderdoes/gitflow-avh
# Verify installation
git flow version
Conclusion
Git Flow is a powerful workflow for teams managing planned releases and multiple versions in production. Its strict structure brings discipline and predictability, but can be excessive for simple projects or teams doing continuous deployment. Choose Git Flow if stability and structured process are priorities.
🎯 Key Points
- Two permanent branches: main (production) and develop (integration)
- Feature branches for new functionalities
- Release branches to prepare releases
- Hotfix branches for critical bugs in production
- Ideal for planned releases and large teams







