Gitflow Workflow

Quick Summary

Gitflow is a structured branching model designed for projects with scheduled releases. It uses five branch types: main (production), develop (integration), feature/* (new work), release/* (pre-release prep), and hotfix/* (emergency fixes). While heavier than trunk-based development, it provides clear structure for teams managing complex release cycles.

---

Branch Architecture

gitGraph
    commit id: "v1.0" tag: "v1.0"
    branch develop
    commit id: "Setup develop"
    branch feature/auth
    commit id: "Add login"
    commit id: "Add register"
    checkout develop
    merge feature/auth id: "Merge auth"
    branch release/1.1
    commit id: "Bump version"
    commit id: "Fix docs"
    checkout main
    merge release/1.1 id: "v1.1" tag: "v1.1"
    checkout develop
    merge release/1.1 id: "Sync release"
    checkout main
    branch hotfix/1.1.1
    commit id: "Fix critical bug"
    checkout main
    merge hotfix/1.1.1 id: "v1.1.1" tag: "v1.1.1"
    checkout develop
    merge hotfix/1.1.1 id: "Sync hotfix"

---

Branch Types

Branch	Lifetime	Created From	Merges Into	Purpose
main	Permanent	—	—	Production-ready code, tagged releases
develop	Permanent	main	—	Integration branch for features
feature/*	Temporary	develop	develop	New features and enhancements
release/*	Temporary	develop	main + develop	Pre-release stabilization
hotfix/*	Temporary	main	main + develop	Emergency production fixes

---

Workflow Steps

Feature Development

# 1. Create feature branch from develop
git checkout develop
git pull origin develop
git checkout -b feature/user-dashboard

# 2. Work on the feature (multiple commits)
git add .
git commit -m "feat: add dashboard layout"
git commit -m "feat: add chart components"

# 3. Merge back to develop
git checkout develop
git pull origin develop
git merge --no-ff feature/user-dashboard -m "Merge feature/user-dashboard"
git push origin develop

# 4. Cleanup
git branch -d feature/user-dashboard

Creating a Release

# 1. Create release branch from develop
git checkout develop
git checkout -b release/2.0

# 2. Stabilize (bug fixes, version bumps, docs)
git commit -m "chore: bump version to 2.0.0"
git commit -m "fix: correct pagination bug"

# 3. Merge to main (deploy)
git checkout main
git merge --no-ff release/2.0 -m "Release v2.0.0"
git tag -a v2.0.0 -m "Version 2.0.0"
git push origin main --tags

# 4. Merge back to develop (keep fixes)
git checkout develop
git merge --no-ff release/2.0 -m "Merge release/2.0 back to develop"
git push origin develop

# 5. Cleanup
git branch -d release/2.0

Hotfix (Emergency)

# 1. Create hotfix from main
git checkout main
git checkout -b hotfix/2.0.1

# 2. Fix the critical bug
git commit -m "fix: resolve production login crash"

# 3. Merge to main
git checkout main
git merge --no-ff hotfix/2.0.1 -m "Hotfix v2.0.1"
git tag -a v2.0.1 -m "Hotfix 2.0.1"
git push origin main --tags

# 4. Merge to develop (keep the fix)
git checkout develop
git merge --no-ff hotfix/2.0.1 -m "Merge hotfix/2.0.1"
git push origin develop

# 5. Cleanup
git branch -d hotfix/2.0.1

---

When to Use Gitflow

Scenario	Use Gitflow?
Scheduled releases (weekly, monthly)	✅ Yes
Mobile apps (App Store review cycle)	✅ Yes
Multiple versions maintained simultaneously	✅ Yes
Continuous deployment (deploy every commit)	❌ Use trunk-based
Solo developer / small team	❌ Overkill — use simple feature-branch
Rapid iteration / startups	❌ Too heavy — use trunk-based

---

Best Practices

• Always use --no-ff for merges — preserves branch history in the graph
• Tag every release on main — v1.0.0, v1.1.0, etc.
• Never commit directly to main or develop — always branch
• Keep feature branches short-lived — merge within days, not weeks
• Delete branches after merging — prevents branch clutter

What's Next

1. Trunk-Based Development — A simpler alternative for CI/CD teams
2. GitHub Actions & CI/CD — Automate testing and deployment