Git Notes
Master the GitFlow branching model with develop, feature, release, and hotfix branches. Learn when GitFlow is appropriate and how to implement it.
GitFlow was introduced by Vincent Driessen in 2010 and quickly became the most widely adopted branching model for teams with scheduled releases. It defines strict rules about which branches exist, where they come from, and where they merge into. While modern teams increasingly favor simpler workflows, GitFlow remains the standard for enterprise software, mobile applications, and any product with versioned releases.
Understanding GitFlow is essential even if your team does not use it, because you will encounter it in interviews, legacy codebases, and organizations that need the structure it provides.
The Branch Structure
GitFlow uses five types of branches, each with a specific purpose and strict lifecycle rules:
| Branch Type | Purpose | Created From | Merges Into | Lifetime |
|---|---|---|---|---|
| main | Production releases only | - | - | Permanent |
| develop | Integration branch | main (once) | main (via release) | Permanent |
| feature/* | New features | develop | develop | Days to weeks |
| release/* | Release preparation | develop | main AND develop | Days |
| hotfix/* | Emergency production fixes | main | main AND develop | Hours to days |
Starting a Feature
All new development begins by branching from develop:
# Ensure develop is up to date
git checkout develop
git pull origin develop
# Create the feature branch
git checkout -b feature/shopping-cart
# Work on the feature over days...
git add .
git commit -m "feat: add cart data model"
git commit -m "feat: implement add-to-cart logic"
git commit -m "feat: add cart UI components"
git commit -m "test: add cart unit tests"
# Push for backup and collaboration
git push -u origin feature/shopping-cartCompleting a Feature
When the feature is done, merge it back to develop using --no-ff to preserve the feature boundary:
git checkout develop
git pull origin develop
git merge --no-ff feature/shopping-cart -m "Merge feature: shopping cart"
git push origin develop
# Clean up
git branch -d feature/shopping-cart
git push origin --delete feature/shopping-cartThe --no-ff flag is crucial in GitFlow. It creates a merge commit even when a fast-forward is possible, preserving a clear record of the feature's boundaries in history. You can see exactly which commits belonged to which feature, and you can revert an entire feature by reverting a single merge commit.
Creating a Release
When develop has accumulated enough features for a release, create a release branch:
# Branch from develop
git checkout -b release/1.2.0 develop
# Only bug fixes and version bumps from here
# NO new features allowed on release branches!
echo "1.2.0" > VERSION
git commit -am "chore: bump version to 1.2.0"
# Fix any release-blocking bugs
git commit -am "fix: correct date format in invoice PDF"Finishing a Release
The release branch merges into BOTH main (for production) and develop (to carry bug fixes back):
# Merge to main
git checkout main
git merge --no-ff release/1.2.0 -m "Release 1.2.0"
git tag -a v1.2.0 -m "Version 1.2.0"
# Merge back to develop (bug fixes during release prep)
git checkout develop
git merge --no-ff release/1.2.0 -m "Merge release/1.2.0 back to develop"
# Clean up
git branch -d release/1.2.0
git push origin main develop --tagsHotfix Workflow
Hotfixes are for critical production bugs that cannot wait for the next release:
# Branch directly from main (production code)
git checkout -b hotfix/1.2.1 main
# Fix the critical bug
git commit -am "fix: patch SQL injection vulnerability"
echo "1.2.1" > VERSION
git commit -am "chore: bump version to 1.2.1"
# Merge to main immediately
git checkout main
git merge --no-ff hotfix/1.2.1 -m "Hotfix 1.2.1"
git tag -a v1.2.1 -m "Hotfix 1.2.1 - security patch"
# Also merge to develop
git checkout develop
git merge --no-ff hotfix/1.2.1 -m "Merge hotfix/1.2.1 to develop"
# Clean up
git branch -d hotfix/1.2.1
git push origin main develop --tagsThe dual merge ensures the hotfix reaches both the current production state and the ongoing development branch.
When GitFlow Is the Right Choice
Good fit:
- Mobile apps with App Store/Play Store release cycles
- Enterprise software with versioned installations
- Products supporting multiple versions simultaneously
- Regulated industries requiring release documentation
- Large teams (10+) needing clear process boundaries
Poor fit:
- Web applications with continuous deployment
- Small teams (under 5 developers)
- Microservices architecture
- Startups moving fast with daily deploys
- Projects without scheduled release dates
Common Mistakes
Mistake 1: Merging features directly to main. In GitFlow, features always go to develop. Main only receives merges from release and hotfix branches.
Mistake 2: Forgetting to merge hotfixes back to develop. If you only merge to main, the next release from develop will reintroduce the bug.
Mistake 3: Adding new features to release branches. Release branches are for stabilization only — bug fixes, documentation, and version bumps.
Mistake 4: Not using --no-ff for merges. Fast-forward merges lose the branch boundary information that makes GitFlow history readable.
Interview Questions
Q1: What is GitFlow and when should you use it?
GitFlow is a branching model with five branch types: main, develop, feature, release, and hotfix. Each has strict creation and merge rules. Use it for projects with scheduled versioned releases, multiple supported versions, or when regulatory compliance requires clear release documentation.
Q2: What is the difference between main and develop in GitFlow?
Main always reflects the current production state — every commit on main is tagged as a release version. Develop is the integration branch where completed features accumulate until they are ready to form a release. Features merge to develop; releases merge to main.
Q3: How do hotfixes work in GitFlow?
Hotfixes branch from main (the production state), contain only the urgent fix, and merge back to both main (with a new version tag) and develop (so the fix is included in future releases). This ensures production gets fixed immediately without waiting for the next release cycle.
Q4: Why use --no-ff for GitFlow merges?
The --no-ff flag forces creation of merge commits even when fast-forward is possible. This preserves clear feature boundaries in history, making it easy to identify which commits belonged to which feature, and enabling clean reverts of entire features with a single revert of the merge commit.
Q5: What are the drawbacks of GitFlow?
Complexity (five branch types with strict rules), overhead for small teams, long-lived branches that can diverge significantly causing merge conflicts, not suited for continuous deployment, and mental burden of remembering which branch merges where.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for GitFlow Workflow - Structured Release Management.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, real, world, workflows, gitflow
Related Git & GitHub Topics