Gitflow branching strategy

Why Do We Need Gitflow Branching Strategy?

When teams are small (1–2 devs), you can survive on “commit to main” 😅.
But when you grow to 5, 10, 50+ developers, multiple features, urgent fixes, releases happening in parallel — chaos starts.
If you don’t have a strong branching strategy:

• 🚨 Hotfixes will collide with feature releases.
• 🐛 Bug fixes might accidentally go to production unfinished.
• 🚀 Feature delivery slows down because everyone fights over merge conflicts.
• 😵‍💫 Release management becomes hell: what should go live, what should not?

Gitflow brings discipline and clear separation between:

TypePurposefeature/*New features safely developed in isolationbugfix/*Bug fixes worked separatelyhotfix/*Urgent production patchesrelease/*Prepares a stable version for productiondevelopActive development aggregationmainProduction-ready code only

PS: Gitflow helps teams move fast, fix fast, and release clean without breaking each other.

GitFlow Overview:

👨‍💻 Developer commits feature to a feature/ branch — Work safely without touching critical code.

🚀 Open PR from feature/ to develop — Merge feature after review and testing.

🛠️ Bug found? Create bugfix/ branch — Fix and merge back cleanly to develop.

🚨 Critical issue in production? Start hotfix/ from main — Patch immediately without waiting for releases.

🔁 Merge hotfix back to both main and develop — Production is saved, development stays updated.

📦 Ready to release? Create a release/ branch — Prepare a clean, tested production version.

✅ Open PR from release/ to main after tests pass — Deploy stable code to production.

Get Saj Sah’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

🔄 Merge release/ back to develop too — Keep develop updated with latest stable changes.

Now, let’s discuss each component in detail as a use case with the required git commands:

👨‍💻 Developer Commits Feature to feature/ Branch

Action: Create a new feature branch from develop.

git checkout develop
# Always pull latest develop
git pull origin develop
# Create new feature branch
git checkout -b feature/awesome-feature

Manual Step: Develop new feature locally, commit changes.

git add .
git commit -m "feat: add new feature"

🚀 Open PR from feature/ to develop

Action: Push branch and open Pull Request (PR).

git push origin feature/new feature

Manual Step:

• Go to GitHub/GitLab/Bitbucket.
• Open a PR: feature/awesome-feature → develop.
• Request code reviews.

🛠️ Bug Found? Create bugfix/ Branch

Action: Branch off from develop.

git checkout develop
git pull origin develop
git checkout -b bugfix/login-issue

Manual Step:

• Fix the bug.
• Commit the fix.

git add .
git commit -m "fix: resolve login issue"

Push and open PR.

git push origin bugfix/login-issue

Open PR: bugfix/login-issue → develop.

🚨 Critical Issue in Production? Start hotfix/ from main

Action: Branch from main immediately.

git checkout main
git pull origin main
git checkout -b hotfix/urgent-patch

Manual Step:

• Patch the urgent issue.
• Commit your patch.

git add .
git commit -m "hotfix: urgent patch for production"

Push and open PR.

git push origin hotfix/urgent-patch

Open PR: hotfix/urgent-patch → main.

🔁 Merge Hotfix back to both main and develop

Action:

• After hotfix PR is merged into main, also merge it into develop.

git checkout develop
git pull origin develop
git merge main

Manual Step:

• Resolve conflicts (if any).
• Push updated develop branch.

git push origin develop

📦 Ready to Release? Create a release/ Branch

Action: From develop, cut a release branch.

git checkout develop
git pull origin develop
git checkout -b release/v1.0

Manual Step:

• Finalize version numbers.
• Final testing, bugfixes.
• Commit if needed.

git commit -am "prepare release v1.0"

Push branch:

git push origin release/v1.0

Open PR: release/v1.0 → main.

✅ Open PR from release/ to main After Tests Pass

Manual Step:

• Review and approve PR.
• Merge into main for production deployment.

Deploy production manually or trigger CI/CD pipelines.

🔄 Merge release/ Back to develop Too

Action: Ensure develop branch gets the final release changes too.

git checkout develop
git pull origin develop
git merge release/v1.0

Manual Step:

• Resolve conflicts if any.
• Push updated develop.

git push origin develop

📋 Few Things to Consider

⚙️ Automation Pipelines
Set up automated pipelines for each environment — from build to deployment — triggered by branch updates (e.g., auto-deploy to test environment when merged into develop).

🏷️ Branch Naming Conventions
Follow a strict naming convention for branches like feature/*, release/*, and hotfix/* to maintain clarity and consistency.

🤝 Collaboration Guidelines
Define clear merging rules. Pull Requests (PRs) must be reviewed, and important branches such as main and release/* should have protection rules to prevent direct changes.

🧪 Testing Strategies
Incorporate testing at every stage. Feature branches should include unit tests, while integration and end-to-end tests should be done after merging into develop or release/*.

🔥 Key Points:

• Always pull latest before creating branches!
• Use semantic, clear branch names.
• Hotfixes must go to both main and develop.
• PR reviews are mandatory to maintain code quality.

🧠 Final Thought

Gitflow is not just a workflow; it’s a way to bring structure, speed, and safety into your development lifecycle. When applied with discipline, it saves teams from chaos and accelerates delivery. Master it once, and it will become second nature to build, fix, and deploy with confidence.