This guide explains the classic Gitflow-style branching model: two long-lived branches for stability, plus short-lived branches for features, releases, and emergency fixes. It is useful for DevOps and engineering teams that need parallel development with controlled production releases.
Originally published on 2012-01-07; fully revised and updated.
This article was originally posted as a repost of a well-known Git branching approach. Useful original references are preserved: Git, Why Git Is Better Than X, and Git vs SVN.

How this model is organized
The model keeps one shared repository (commonly called origin) as the team reference point, while still using Git’s distributed workflow. Developers can collaborate through origin and, when needed, add each other as remotes for peer collaboration.
master(oftenmainin modern repos): production-ready history.develop: integration branch for upcoming release work.- Feature branches: isolated implementation work, merged back to
develop. - Release branches: release hardening, version prep, and final validation.
- Hotfix branches: urgent production fixes branched from
master.
Branch types and merge rules
| Branch type | Create from | Merge into | Primary purpose | Naming pattern |
|---|---|---|---|---|
master (or main) | Long-lived branch | Not applicable | Tracks production-ready commits | master or main |
develop | Long-lived branch | master at release time | Integrates completed development work | develop |
| Feature branch | develop | develop | Build and test a feature in isolation | feature-* (or team convention) |
| Release branch | develop | master and develop | Stabilize a specific release version | release-* |
| Hotfix branch | master | master and develop (or active release branch) | Patch production quickly | hotfix-* |
Typical lifecycle from feature to production
flowchart LR
A[develop branch] --> B[feature branch]
B --> C[merge to develop]
C --> D[release branch]
D --> E[merge to master]
E --> F[tag version]
D --> G[merge back to develop]
E --> H[hotfix branch]
H --> I[merge to master]
H --> J[merge to develop or release]
I --> K[tag hotfix]
Important exception: if a release branch is currently active, merge hotfixes into that release branch first, then back into develop when the release branch is completed.
Command reference for common Gitflow operations
Create and merge a feature branch
git checkout develop
git pull origin develop
git checkout -b feature-login-api
# implement and commit changes
git add .
git commit -m "feat: add login api"
git checkout develop
git merge --no-ff feature-login-api
git push origin develop
git branch -d feature-login-apiCode language: PHP (php)
Create and finish a release branch
git checkout develop
git pull origin develop
git checkout -b release-1.2.0
# update version files and release notes
git commit -am "chore: prepare release 1.2.0"
git checkout master
git merge --no-ff release-1.2.0
git tag -a 1.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 master develop --tagsCode language: CSS (css)
Create and finish a hotfix branch
git checkout master
git pull origin master
git checkout -b hotfix-1.2.1
# fix production issue
git commit -am "fix: resolve critical production issue"
git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1 -m "Hotfix 1.2.1"
# if no active release branch exists
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1
git push origin master develop --tagsCode language: CSS (css)
Optional: enforce non fast forward merges by default
git config --global merge.ff falseCode language: PHP (php)
Gitflow compared with trunk-based development
| Approach | Best for | Release style | Operational trade-off |
|---|---|---|---|
| Gitflow | Teams that need staged releases and explicit release hardening | Versioned releases via release branches and tags | Clear structure, but more branch management overhead |
| Trunk-based development | Teams shipping very frequently with strong CI and feature flagging | Continuous integration on a short-lived branch model | Faster flow, but requires strict discipline and automation maturity |
Common pitfalls and best practices
- Protect long-lived branches. Require pull requests, reviews, and CI checks on
master/mainanddevelop. - Always back-merge fixes. Every release or hotfix change must be merged back so future releases do not regress.
- Keep release branches short-lived. Treat them as stabilization branches, not feature branches.
- Tag every production release. Tags make rollback and auditing much easier.
- Use one naming convention. Keep branch names predictable for automation and team clarity.
For historical context from the original repost, the diagram source archive is still linked here: gitflow-model.src.key.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals