GitFlow
Printed from:
Complete GitFlow Cheatsheet
Table of Contents
- GitFlow Overview
- AVH vs nvie Forks
- Installation & Setup
- Branch Structure
- GitFlow Initialization
- Feature Development
- Release Management
- Hotfix Management
- Bugfix Branches (AVH)
- Support Branches
- GitFlow vs Manual Git Commands
- Best Practices
- Common Workflows
- Signing Releases & Hotfixes
- CI / CD Considerations
- Troubleshooting
- GitFlow Alternatives
- Configuration Files
- Quick Reference
GitFlow Overview
GitFlow is a branching model for Git, originally described by Vincent Driessen in 2010, that defines a strict branching model around project releases. It is best suited for teams that ship versioned software with scheduled releases, not for trunk-based / continuous delivery workflows.
Core Principles
- Two long-lived branches:
main(production) anddevelop(integration). - Supporting branches:
feature/*,release/*,hotfix/*,bugfix/*(AVH),support/*. - Parallel development of multiple features on independent branches.
- Release preparation isolated on its own branch so
developkeeps moving. - Emergency fixes are produced from
mainand merged back into bothmainanddevelop.
GitFlow Diagram
12345678910main ──●────────●────────●──────── (production releases) │ │ │ release │ ┌────●────●───┘ (release preparation) │ │ │ │ develop ●────●────●────●────●───── (integration branch) │ │ │ feature │ └──●─────┘ (feature development) │ hotfix └──────●───●── (emergency fixes)
AVH vs nvie Forks
Two implementations are in use; commands differ slightly:
| Aspect | nvie (original) | AVH Edition (active) |
|---|---|---|
| Maintenance | Archived | Actively maintained |
| Bugfix branches | ❌ | ✅ git flow bugfix |
feature delete | ❌ | ✅ |
| Hooks | Basic | Extended hooks |
| Default install on macOS | git-flow | git-flow-avh |
Prefer AVH unless your team has a hard reason to use nvie.
Installation & Setup
Using Package Managers
12345678910111213141516171819# macOS (Homebrew)
brew install git-flow-avh
# Ubuntu/Debian
sudo apt-get install git-flow
# CentOS/RHEL/Fedora
sudo yum install gitflow
sudo dnf install git-flow
# Windows (Chocolatey)
choco install gitflow-avh
# Windows (Scoop)
scoop install git-flow
# Arch Linux
sudo pacman -S gitflow-avh
Manual Installation
12345# AVH edition
git clone --recursive https://github.com/petervanderdoes/gitflow-avh.git
cd gitflow-avh
sudo make install
Verify Installation
1234git flow version
git flow help
which git-flow
Branch Structure
Main (long-lived) Branches
main(formerlymaster): Production-ready code. Tagged with version numbers. Always deployable.develop: Integration branch. Latest delivered development changes. Base for new feature branches.
Supporting (short-lived) Branches
| Type | Naming | Base | Merges back to | Purpose |
|---|---|---|---|---|
| Feature | feature/<name> | develop | develop | Develop new features |
| Release | release/<version> | develop | main + develop | Prepare a production release |
| Hotfix | hotfix/<name> | main | main + develop | Fix critical production bugs |
| Bugfix | bugfix/<name> (AVH) | develop | develop / release | Non-critical fixes during release |
| Support | support/<version> | main tag | (long-lived) | Maintain older major versions |
GitFlow Initialization
123456789# Interactive initialization
git flow init
# Use defaults (non-interactive)
git flow init -d
# Force re-init (overwrite existing GitFlow config)
git flow init -f
Initialization Prompts
You'll be asked for:
- Production branch name (default:
main) - Development branch name (default:
develop) - Feature branch prefix (default:
feature/) - Release branch prefix (default:
release/) - Hotfix branch prefix (default:
hotfix/) - Bugfix branch prefix (default:
bugfix/, AVH only) - Support branch prefix (default:
support/) - Version tag prefix (often
v→ tags likev1.2.0)
Inspect Current Config
123git flow config git config --get-regexp gitflow
Post-Initialization
1234git push -u origin main
git push -u origin develop
git branch -a # verify
Feature Development
Start a Feature
1234567git flow feature start <feature-name>
git flow feature start <feature-name> <base> # From a specific commit
# Examples
git flow feature start user-authentication
git flow feature start JIRA-123-checkout
Work on a Feature
123456789101112git checkout feature/<feature-name>
git add .
git commit -m "feat: add registration endpoint"
git push origin feature/<feature-name>
# Make the feature visible to others
git flow feature publish <feature-name>
# Track a published feature locally
git flow feature pull origin <feature-name>
Finish a Feature
123456789101112131415# Merge to develop and delete branch
git flow feature finish <feature-name>
# Keep the branch after merging
git flow feature finish -k <feature-name>
# Rebase on develop instead of merge
git flow feature finish -r <feature-name>
# Force-finish (even with unmerged changes)
git flow feature finish -F <feature-name>
# Squash all feature commits into one
git flow feature finish -S <feature-name> # AVH
Feature Management
123456git flow feature list
git flow feature list -v # Verbose
git flow feature track <feature-name>
git flow feature delete <feature-name> # AVH
git flow feature checkout <feature-name>
Release Management
Start a Release
1234567git flow release start <version>
git flow release start <version> <base>
# Examples
git flow release start 1.2.0
git flow release start 2.0.0-rc1
Work on a Release
123456789git checkout release/<version>
# Bump version
echo "1.2.0" > VERSION
git commit -am "chore: bump version to 1.2.0"
# Update changelog, docs, last-minute bug fixes...
git flow release publish <version> # Share with team
Finish a Release
12345678910111213141516# Default: merge to main, tag, merge back to develop, delete branch
git flow release finish <version>
# Tag with a specific message
git flow release finish -m "Release 1.2.0" <version>
# Keep release branch after finishing
git flow release finish -k <version>
# Sign the tag (GPG/SSH)
git flow release finish -s <version>
git flow release finish -u <key-id> <version> # Sign with specific key
# Push everything at once (AVH)
git flow release finish -p <version>
Release Management
1234git flow release list
git flow release track <version>
git flow release delete <version> # AVH
Hotfix Management
Start a Hotfix
1234567git flow hotfix start <hotfix-name>
git flow hotfix start <hotfix-name> <base-tag>
# Examples
git flow hotfix start 1.2.1
git flow hotfix start security-patch v1.2.0
Work on a Hotfix
1234567git checkout hotfix/<hotfix-name>
git add .
git commit -m "fix: patch critical security vulnerability"
git flow hotfix publish <hotfix-name> # Share if collaborating
Finish a Hotfix
12345678git flow hotfix finish <hotfix-name>
# This merges to main, tags it, then merges back to develop, deletes branch.
git flow hotfix finish -m "Hotfix 1.2.1" <hotfix-name>
git flow hotfix finish -s <hotfix-name> # Signed tag
git flow hotfix finish -p <hotfix-name> # Auto-push (AVH)
Hotfix Management
123git flow hotfix list
git flow hotfix delete <hotfix-name> # AVH
Bugfix Branches (AVH)
A bugfix/* branch is like a feature, but intended for non-critical fixes while a release branch is open. They base off develop (or release/*) and merge back the same way.
1234567git flow bugfix start <name> git flow bugfix start <name> <base> git flow bugfix publish <name> git flow bugfix finish <name> git flow bugfix list git flow bugfix delete <name>
Support Branches
Long-lived maintenance branches for older releases. They never merge back to main or develop.
1234567891011git flow support start <version> <base-tag>
# Example: maintain the 1.x line from tag v1.2.0
git flow support start 1.x v1.2.0
# Maintain
git checkout support/1.x
git commit -am "Backport security fix to 1.x"
git tag v1.2.1
git push origin support/1.x --tags
GitFlow vs Manual Git Commands
Feature Workflow
1234567891011121314# GitFlow
git flow feature start user-auth
# ... work ...
git flow feature finish user-auth
# Manual equivalent
git checkout develop && git pull origin develop
git checkout -b feature/user-auth
# ... work ...
git checkout develop && git pull origin develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth
git push origin develop
Release Workflow
12345678910111213141516# GitFlow
git flow release start 1.2.0
# ... prep ...
git flow release finish 1.2.0
# Manual equivalent
git checkout develop && git pull origin develop
git checkout -b release/1.2.0
# ... prep ...
git checkout main && git pull origin 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
git branch -d release/1.2.0
git push origin main develop --tags
Hotfix Workflow
123456789101112131415# GitFlow
git flow hotfix start 1.2.1
# ... fix ...
git flow hotfix finish 1.2.1
# Manual equivalent
git checkout main && git pull origin main
git checkout -b hotfix/1.2.1
# ... fix ...
git checkout main && git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix 1.2.1"
git checkout develop && git merge --no-ff hotfix/1.2.1
git branch -d hotfix/1.2.1
git push origin main develop --tags
See What GitFlow Will Do
123git flow feature finish --showcommands user-auth git flow release finish --showcommands 1.2.0
Best Practices
Branch Naming Conventions
12345678910feature/user-authentication feature/payment-integration feature/JIRA-123-checkout release/1.2.0 release/2024.01 hotfix/1.2.1 hotfix/cve-2024-1234 bugfix/login-redirect support/1.x
Commit Message Conventions (Conventional Commits)
1234567891011feat: a new feature fix: a bug fix docs: documentation only style: formatting (no code change) refactor: code change that is neither feature nor fix perf: performance improvement test: adding or fixing tests chore: tooling, build, deps ci: CI configuration revert: reverts a previous commit
Semantic Versioning
123456789101112MAJOR.MINOR.PATCH 1.0.0 initial release 1.1.0 new features (minor) 1.1.1 bug fixes (patch) 2.0.0 breaking changes (major) 1.2.0-alpha.1 pre-release 1.2.0-beta.2 1.2.0-rc.1 1.2.0+build.42 build metadata
Team Collaboration
- Always start features from the latest
develop. - Keep features small and short-lived (< 1 week ideally).
- Sync long-running features regularly:
git merge develop(orgit rebase developif your team prefers linear history). - Publish feature branches early to enable code review via PRs/MRs.
- Tag every release on
main. - Protect
mainanddevelopwith branch protection rules.
Common Workflows
Standard Feature Development
123456789101112git flow feature start user-dashboard
# work...
git add . && git commit -m "feat: dashboard layout"
git commit -am "feat: dashboard API integration"
git commit -am "test: dashboard component tests"
git checkout develop && git pull origin develop
git checkout feature/user-dashboard && git merge develop
git flow feature finish user-dashboard
git push origin develop
Release Process
123456789git flow release start 1.3.0
echo "1.3.0" > VERSION
git commit -am "chore: bump version to 1.3.0"
git commit -am "docs: update CHANGELOG for v1.3.0"
git commit -am "fix: edge case in user validation"
git flow release finish -s 1.3.0
git push origin main develop --tags
Emergency Hotfix
123456git flow hotfix start 1.3.1
git commit -am "fix: critical payment processing bug"
git flow hotfix finish -s 1.3.1
git push origin main develop --tags
# Deploy immediately.
Long-running Feature (with periodic syncs)
123456789git flow feature start complex-feature
while developing; do
git commit -am "progress"
git checkout develop && git pull
git checkout feature/complex-feature && git merge develop
git push origin feature/complex-feature
done
git flow feature finish complex-feature
Signing Releases & Hotfixes
123456789101112131415# One-time setup
git config --global user.signingkey <GPG-KEY-ID> # or SSH key (Git 2.34+)
git config --global commit.gpgsign true
git config --global tag.gpgsign true
git config --global gpg.format ssh # if using SSH signing
git config --global user.signingkey ~/.ssh/id_ed25519.pub
# Per-finish signed tag
git flow release finish -s 1.2.0
git flow hotfix finish -s 1.2.1
# Verify
git tag -v v1.2.0
git log --show-signature
CI / CD Considerations
- Tag pushes (
v*) onmainare a natural trigger for production deployments. - Push to
developtriggers staging / integration builds. release/*branches trigger release-candidate builds.hotfix/*branches typically run a faster pipeline targeting prod after merge.- Avoid the temptation to deploy directly from a feature branch — that's GitHub Flow / trunk-based territory.
1234567891011# Example: GitHub Actions trigger map
on:
push:
branches:
- main
- develop
- 'release/**'
- 'hotfix/**'
tags:
- 'v*'
Troubleshooting
GitFlow Not Initialized
123# Error: Not a gitflow-enabled repo yet
git flow init -d
Branch Already Exists
1234git flow feature checkout <feature-name> # Switch to existing
git branch -D feature/<feature-name> # Or delete and recreate
git flow feature delete <feature-name> # AVH
Merge Conflicts During Finish
123456# git flow finish stops at the conflict — resolve, then continue.
git status
# edit conflicted files
git add <resolved-files>
git flow feature finish <feature-name> # re-run; GitFlow resumes
Remote Tracking Issues
12345# Error: No tracking information
git flow feature publish <feature-name>
# or
git push -u origin feature/<feature-name>
Accidentally Started the Wrong Branch Type
1234git branch -m feature/fix hotfix/fix
git checkout main
# Recreate via the correct command, then delete the misnamed one
Recovery
1234567891011121314151617# Abort an in-progress finish
git merge --abort
git rebase --abort
# Recreate a deleted branch
git branch feature/<name> <sha>
git flow feature list
# Reset GitFlow config
git config --unset gitflow.branch.main
git config --unset gitflow.branch.develop
git flow init -f
# Clean up merged branches
git remote prune origin
git branch --merged | grep -vE '^\*|main$|develop$' | xargs -n 1 git branch -d
Debugging GitFlow
12345678910git flow config
git config --get-regexp gitflow
git branch -a
git log --oneline --graph --all
git remote -v
git remote show origin
# Print the underlying git commands a GitFlow command would run
git flow feature finish --showcommands <name>
GitFlow Alternatives
GitHub Flow (continuous delivery)
123main + short-lived feature branches. PR → review → merge → deploy from main.
GitLab Flow (environment branches)
123main → pre-production → production Feature branches merge to main, then promote through environments.
OneFlow
123main + feature/release/hotfix, NO develop branch. Releases are tags on main; hotfixes branch from a release tag.
Trunk-Based Development
1234Everyone commits to main (or short-lived branches that live hours, not days). Feature flags hide unfinished work. Pairs naturally with CD.
Configuration Files
.gitconfig GitFlow Section
123456789101112131415[gitflow "branch"]
master = main
develop = develop
[gitflow "prefix"]
feature = feature/
bugfix = bugfix/
release = release/
hotfix = hotfix/
support = support/
versiontag = v
[gitflow "path"]
hooks = .git/hooks
Shell Aliases
12345678910111213# Add to ~/.bashrc or ~/.zshrc
alias gf='git flow'
alias gff='git flow feature'
alias gffs='git flow feature start'
alias gfff='git flow feature finish'
alias gfr='git flow release'
alias gfrs='git flow release start'
alias gfrf='git flow release finish'
alias gfh='git flow hotfix'
alias gfhs='git flow hotfix start'
alias gfhf='git flow hotfix finish'
alias gfb='git flow bugfix'
Useful Hooks
GitFlow-AVH supports hooks in .git/hooks/:
12345678filter-flow-feature-start-name pre-flow-feature-start post-flow-feature-finish pre-flow-release-start post-flow-release-finish pre-flow-hotfix-finish post-flow-hotfix-finish
Quick Reference
Daily Commands
1234567891011121314151617# Features
git flow feature start <name>
git flow feature publish <name>
git flow feature finish <name>
# Releases
git flow release start <version>
git flow release finish -s <version>
# Hotfixes
git flow hotfix start <name>
git flow hotfix finish -s <name>
# Bugfixes (AVH)
git flow bugfix start <name>
git flow bugfix finish <name>
Branch Overview
1234567git status
git branch -a
git log --oneline --graph --all -20
git checkout develop && git pull origin develop
git checkout main && git pull origin main
Remember: GitFlow is a branching model on top of Git, not a replacement for Git fundamentals. Knowing the underlying commands is essential when something goes wrong.
Continue Learning
Discover more cheatsheets to boost your productivity