Find the Best Cosmetic Hospitals

Explore trusted cosmetic hospitals and make a confident choice for your transformation.

“Invest in yourself — your confidence is always worth it.”

Explore Cosmetic Hospitals

Start your journey today — compare options in one place.

Gitflow Branching Model: Practical Guide to Feature, Release, and Hotfix Branches

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.

Git branching model overview

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 (often main in 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 typeCreate fromMerge intoPrimary purposeNaming pattern
master (or main)Long-lived branchNot applicableTracks production-ready commitsmaster or main
developLong-lived branchmaster at release timeIntegrates completed development workdevelop
Feature branchdevelopdevelopBuild and test a feature in isolationfeature-* (or team convention)
Release branchdevelopmaster and developStabilize a specific release versionrelease-*
Hotfix branchmastermaster and develop (or active release branch)Patch production quicklyhotfix-*

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

ApproachBest forRelease styleOperational trade-off
GitflowTeams that need staged releases and explicit release hardeningVersioned releases via release branches and tagsClear structure, but more branch management overhead
Trunk-based developmentTeams shipping very frequently with strong CI and feature flaggingContinuous integration on a short-lived branch modelFaster 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/main and develop.
  • 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.

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals
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.

Related Posts

Online Git Repository Hosting: Revisiting the 2014 Top 10 with a Modern Selection and Migration Guide

This revised guide preserves the original 2014 list of Git hosting websites and adds a practical framework for evaluating providers today. It also includes a selection workflow and Git commands for safe repository migration.

Read More

Git Troubleshooting for Slow or Hanging Commands: Tracing, Verbose Logs, and Safer Diagnostics

When Git push or clone appears stuck, built-in trace flags can quickly reveal where execution is failing. This guide gives a practical workflow, command patterns, and common pitfalls for collecting actionable Git diagnostics.

Read More

Bash Git Aliases: A Practical Command Set for Faster Daily Git Work

Set up a clean, copy-paste-ready Bash alias collection for common Git commands, then learn when Bash aliases are better than Git’s built-in aliases. This guide also covers safe installation, workflow usage, and common mistakes to avoid.

Read More

What is Git and use cases of Git?

What is Git? Git is a distributed version control system (DVCS) planned to track changes in source code during software development. It was developed by Linus Torvalds…

Read More

What is GitOps?

GitOps is a modern approach to managing and automating the deployment and operation of applications and infrastructure using Git as the single source of truth. In GitOps,…

Read More

What is Git LFS and use cases of Git LFS?

What is Git LFS? Git LFS (Large File Storage) is an extension of the Git version control system that addresses the challenge of managing large files and…

Read More
Subscribe
Notify of
guest
0 Comments
Newest
Oldest Most Voted
0
Would love your thoughts, please comment.x
()
x