From Basic to Advanced: A Complete One-Stop Guide to Gitflow Branching, Releases, Hotfixes, CI/CD, and Governance

1. What is Gitflow?

Gitflow is a structured Git branching model designed for teams that release software in planned versions.

It uses several branch types, each with a specific job:

main / master
develop
feature/*
release/*
hotfix/*
support/* optional

In simple words:

Gitflow is a release-focused branching strategy.

It is especially useful when a team needs:

• scheduled releases
• release stabilization
• hotfix handling
• version tags
• support for older versions
• QA cycles
• approval gates
• controlled production delivery

The original Gitflow model was introduced by Vincent Driessen in 2010 as a branching strategy for developing and releasing version-based software. In his later 2020 note, he warned that teams should not treat Gitflow as a universal standard or dogma, and specifically suggested simpler workflows for continuously delivered web apps.

2. The simplest mental model

Gitflow separates software work into five lanes:

feature work     → feature/*
integration      → develop
release prep     → release/*
production       → main
emergency repair → hotfix/*

flowchart LR
    A[feature/*] --> B[develop]
    B --> C[release/*]
    C --> D[main / production]
    D --> E[hotfix/*]
    E --> D
    E --> B
Code language: CSS (css)

The core idea:

Developers can continue building the next version while another branch is being stabilized for release.

That is the magic of Gitflow.

3. Why Gitflow exists

Without Gitflow, teams often struggle with this problem:

Some developers are building future features.
QA wants to test the next release.
Production has a critical bug.
Customers still need old versions supported.

Gitflow gives each problem a separate branch lane.

AWS describes Gitflow as a model that uses multiple branches to move code from development to production, and says it works well for scheduled release cycles where a collection of features is grouped into a release.

4. Gitflow is not just “more branches”

Bad understanding:

Gitflow = create many branches

Correct understanding:

Gitflow = separate development, release stabilization, production, and hotfix work

A branch in Gitflow must have a clear purpose.

flowchart TD
    A[Need a branch?] --> B{What is the purpose?}
    B -- New feature --> C[feature/*]
    B -- Integrate next release --> D[develop]
    B -- Stabilize release --> E[release/*]
    B -- Production code --> F[main]
    B -- Emergency fix --> G[hotfix/*]
    B -- Old version support --> H[support/*]
    B -- No clear purpose --> I[Do not create branch]
Code language: PHP (php)

5. The full Gitflow branch family

gitGraph
    commit id: "v1.0.0"
    branch develop
    checkout develop
    commit id: "dev work"
    branch feature/login
    checkout feature/login
    commit id: "login 1"
    commit id: "login 2"
    checkout develop
    merge feature/login
    branch release/1.1.0
    checkout release/1.1.0
    commit id: "release fix"
    checkout main
    merge release/1.1.0 tag: "v1.1.0"
    checkout develop
    merge release/1.1.0
    checkout main
    branch hotfix/1.1.1
    checkout hotfix/1.1.1
    commit id: "prod fix"
    checkout main
    merge hotfix/1.1.1 tag: "v1.1.1"
    checkout develop
    merge hotfix/1.1.1
Code language: JavaScript (javascript)

6. Main branches in Gitflow

Gitflow has two long-lived primary branches:

main / master
develop

The original Gitflow model used master; modern teams often rename it to main.

6.1 main branch

The main branch represents production-ready code.

main = production history

Rules:

• Every commit on main should represent a production release or production-ready state.
• Releases are tagged on main.
• Direct pushes should be blocked.
• Only release branches and hotfix branches merge into main.

Vincent Driessen’s original model defines origin/master as the branch where HEAD always reflects a production-ready state; in modern naming, this is usually origin/main.

6.2 develop branch

The develop branch is the integration branch for the next release.

develop = next release integration

Rules:

• Feature branches merge into develop.
• develop should be stable enough for integration testing.
• When develop has enough features for a release, create a release/* branch.
• Hotfixes from production must eventually flow back into develop.

The original model describes develop as the branch where the latest delivered development changes for the next release are integrated.

7. Supporting branches in Gitflow

Gitflow uses short-lived supporting branches.

feature/*
release/*
hotfix/*
support/* optional

Vincent Driessen’s original Gitflow article defines feature, release, and hotfix branches as supporting branches with limited lifetimes and strict rules about where they start and where they merge.

8. Gitflow branch responsibility table

9. Gitflow branch naming standard

Recommended naming

feature/<ticket>-<short-description>
release/<version>
hotfix/<version>-<short-description>
support/<version-or-line>
Code language: HTML, XML (xml)

Examples

feature/EVP-123-add-device-search
feature/EVP-140-payment-retry
release/2.4.0
release/mobile-5.1.0
hotfix/2.4.1-login-crash
hotfix/2.4.2-security-token-rotation
support/1.9-lts
support/2.x

Avoid

my-branch
test
final
new
fix
rajesh-work
release-latest
Code language: PHP (php)

Good branch names should explain purpose before anyone opens the code.

10. Gitflow lifecycle overview

flowchart TD
    A[Start from develop] --> B[Create feature branch]
    B --> C[Develop feature]
    C --> D[Merge feature into develop]
    D --> E{Enough features for release?}
    E -- No --> B
    E -- Yes --> F[Create release branch]
    F --> G[QA / bug fixes / version bump]
    G --> H[Merge release into main]
    H --> I[Tag version]
    I --> J[Merge release back into develop]
    J --> K[Delete release branch]
    H --> L{Production issue?}
    L -- Yes --> M[Create hotfix from main]
    M --> N[Fix and test]
    N --> O[Merge hotfix into main]
    O --> P[Tag patch version]
    P --> Q[Merge hotfix into develop]
Code language: JavaScript (javascript)

11. Step 1: Initialize a Gitflow-style repository

Start with main.

git init
git checkout -b main
echo "# My Project" > README.md
git add README.md
git commit -m "chore: initial commit"
Code language: PHP (php)

Create develop.

git checkout -b develop
git push -u origin main
git push -u origin develop

Now your repository has:

main
develop

12. Step 2: Feature branch workflow

Feature branches are created from develop.

flowchart LR
    A[develop] --> B[feature/add-login]
    B --> C[work + commits]
    C --> D[pull request]
    D --> E[merge into develop]
Code language: CSS (css)

Create a feature branch

git checkout develop
git pull --ff-only origin develop
git checkout -b feature/EVP-123-add-login

Work and commit

git add .
git commit -m "feat(auth): add login endpoint"
Code language: JavaScript (javascript)

Push feature branch

git push -u origin feature/EVP-123-add-login

Merge feature into develop

Option A: via pull request / merge request.

Option B: command line.

git checkout develop
git pull --ff-only origin develop
git merge --no-ff feature/EVP-123-add-login
git push origin develop

The original Gitflow article uses --no-ff when merging finished feature branches into develop so the historical existence of the feature branch remains visible.

Delete feature branch

git branch -d feature/EVP-123-add-login
git push origin --delete feature/EVP-123-add-login
Code language: JavaScript (javascript)

13. Feature branch rules

Feature branches should:

• start from develop
• be short-lived
• contain one feature or one logical change
• be reviewed before merging
• pass CI before merging
• merge only into develop
• be deleted after merge

Feature branches should not:

• start from main
• merge directly into main
• include multiple unrelated features
• live for months
• contain production hotfixes
• contain release-only version bumps

14. Step 3: Release branch workflow

A release branch is created from develop when the team decides that the next release has enough features.

flowchart TD
    A[develop] --> B[release/2.4.0]
    B --> C[QA testing]
    C --> D[Bug fixes only]
    D --> E[Version bump / release notes]
    E --> F[Merge to main]
    F --> G[Tag v2.4.0]
    B --> H[Merge back to develop]
Code language: CSS (css)

Create a release branch

git checkout develop
git pull --ff-only origin develop
git checkout -b release/2.4.0
git push -u origin release/2.4.0

Bump version

Example file:

VERSION=2.4.0

Commit:

git add VERSION
git commit -m "chore(release): bump version to 2.4.0"
git push origin release/2.4.0
Code language: JavaScript (javascript)

Fix release bugs

git add .
git commit -m "fix(release): correct payment retry configuration"
git push origin release/2.4.0
Code language: JavaScript (javascript)

Finish release

Merge into main.

git checkout main
git pull --ff-only origin main
git merge --no-ff release/2.4.0
git tag -a v2.4.0 -m "Release v2.4.0"
git push origin main v2.4.0
Code language: JavaScript (javascript)

Merge back into develop.

git checkout develop
git pull --ff-only origin develop
git merge --no-ff release/2.4.0
git push origin develop

Delete release branch.

git branch -d release/2.4.0
git push origin --delete release/2.4.0
Code language: JavaScript (javascript)

The original Gitflow model says release branches start from develop, merge back into both main and develop, and are used for final release preparation such as minor bug fixes and release metadata.

15. Release branch rules

Allowed on release/*:

bug fixes
version bump
release notes
documentation correction
safe configuration correction
test fixes related to release

Not allowed on release/*:

new features
large refactors
experimental work
unrelated cleanup
risky dependency upgrades
major architecture changes
Code language: JavaScript (javascript)

Important rule:

A release branch is for stabilization, not innovation.

16. Step 4: Hotfix branch workflow

A hotfix branch is created when production is broken and cannot wait for the next scheduled release.

flowchart TD
    A[Production issue] --> B[Create hotfix from main]
    B --> C[Fix issue]
    C --> D[Test]
    D --> E[Merge into main]
    E --> F[Tag patch release]
    F --> G[Merge into develop]
    G --> H[Delete hotfix branch]
Code language: CSS (css)

Create hotfix branch

git checkout main
git pull --ff-only origin main
git checkout -b hotfix/2.4.1-login-crash

Bump patch version

echo "2.4.1" > VERSION
git add VERSION
git commit -m "chore(hotfix): bump version to 2.4.1"
Code language: CSS (css)

Fix production bug

git add .
git commit -m "fix(auth): prevent crash on expired login token"
git push -u origin hotfix/2.4.1-login-crash
Code language: JavaScript (javascript)

Finish hotfix

Merge into main.

git checkout main
git pull --ff-only origin main
git merge --no-ff hotfix/2.4.1-login-crash
git tag -a v2.4.1 -m "Hotfix v2.4.1"
git push origin main v2.4.1
Code language: JavaScript (javascript)

Merge into develop.

git checkout develop
git pull --ff-only origin develop
git merge --no-ff hotfix/2.4.1-login-crash
git push origin develop

Delete branch.

git branch -d hotfix/2.4.1-login-crash
git push origin --delete hotfix/2.4.1-login-crash
Code language: JavaScript (javascript)

In the original model, hotfix branches start from master/main and must merge back into both master/main and develop; if a release branch currently exists, the hotfix should also be merged into that release branch so the release includes the fix.

17. Hotfix branch rules

Hotfix branches should:

• start from main or the production tag
• fix only the production issue
• be small
• be reviewed quickly
• run critical tests
• merge into main
• be tagged as a patch release
• merge back into develop
• merge into active release/* branch if one exists

Hotfix branches should not:

• include new features
• include refactoring
• include broad dependency upgrades
• include unrelated cleanup
• bypass source control
• remain open after deployment

18. What if a release branch exists during hotfix?

This is a common Gitflow confusion.

Situation:

main = production v2.4.0
develop = future v2.6.0 work
release/2.5.0 = currently in QA
production has critical bug

Flow:

flowchart TD
    A[main] --> B[hotfix/2.4.1]
    B --> C[merge to main]
    C --> D[tag v2.4.1]
    B --> E[merge to release/2.5.0]
    E --> F[eventually release branch merges to develop]
    B --> G[optionally merge to develop immediately if needed]
Code language: CSS (css)

Practical rule:

Hotfix must reach every branch that still needs the fix.

Usually:

• merge hotfix into main
• merge hotfix into active release/*
• merge hotfix into develop now or via release branch later

19. Optional support branch workflow

Use support branches when older versions must be maintained.

support/1.9-lts
support/2.x

flowchart LR
    A[main latest] --> B[support/2.x]
    A --> C[support/1.9-lts]
    D[security fix] --> B
    D --> C
Code language: CSS (css)

Create support branch

git checkout v1.9.0
git checkout -b support/1.9-lts
git push -u origin support/1.9-lts

Backport fix

git checkout support/1.9-lts
git cherry-pick <fix-commit-sha>
git push origin support/1.9-lts
Code language: HTML, XML (xml)

Tag support release

git tag -a v1.9.7 -m "Support release v1.9.7"
git push origin v1.9.7
Code language: CSS (css)

Use support branches only when the product genuinely needs long-term maintenance for older versions.

20. Gitflow with Semantic Versioning

Gitflow works naturally with Semantic Versioning.

MAJOR.MINOR.PATCH
Code language: CSS (css)

Examples:

v1.0.0
v1.1.0
v1.1.1
v2.0.0
Code language: CSS (css)

Semantic Versioning defines major versions for incompatible API changes, minor versions for backward-compatible functionality, and patch versions for backward-compatible bug fixes.

Mapping Gitflow to SemVer

Example:

release/2.4.0 → tag v2.4.0
hotfix/2.4.1-login-crash → tag v2.4.1
support/1.9-lts → tag v1.9.8

21. Gitflow with Conventional Commits

Conventional Commits makes Gitflow cleaner because commit messages become meaningful for changelogs and release notes.

Format:

<type>(optional-scope): <description>
Code language: HTML, XML (xml)

Examples:

feat(auth): add OAuth login
fix(payment): retry gateway timeout
chore(release): bump version to 2.4.0
docs(runbook): add hotfix process
Code language: HTTP (http)

The Conventional Commits specification defines a lightweight structure for commit messages that gives human-readable and machine-readable meaning to commit history and aligns with SemVer concepts like features, fixes, and breaking changes.

22. Gitflow commit type guide

23. Gitflow command cheat sheet

Create develop

git checkout main
git checkout -b develop
git push -u origin develop

Create feature

git checkout develop
git pull --ff-only origin develop
git checkout -b feature/EVP-123-add-login

Finish feature

git checkout develop
git pull --ff-only origin develop
git merge --no-ff feature/EVP-123-add-login
git push origin develop
git branch -d feature/EVP-123-add-login
git push origin --delete feature/EVP-123-add-login
Code language: JavaScript (javascript)

Create release

git checkout develop
git pull --ff-only origin develop
git checkout -b release/2.4.0
git push -u origin release/2.4.0

Finish release

git checkout main
git pull --ff-only origin main
git merge --no-ff release/2.4.0
git tag -a v2.4.0 -m "Release v2.4.0"
git push origin main v2.4.0

git checkout develop
git pull --ff-only origin develop
git merge --no-ff release/2.4.0
git push origin develop

git branch -d release/2.4.0
git push origin --delete release/2.4.0
Code language: JavaScript (javascript)

Create hotfix

git checkout main
git pull --ff-only origin main
git checkout -b hotfix/2.4.1-login-crash

Finish hotfix

git checkout main
git pull --ff-only origin main
git merge --no-ff hotfix/2.4.1-login-crash
git tag -a v2.4.1 -m "Hotfix v2.4.1"
git push origin main v2.4.1

git checkout develop
git pull --ff-only origin develop
git merge --no-ff hotfix/2.4.1-login-crash
git push origin develop

git branch -d hotfix/2.4.1-login-crash
git push origin --delete hotfix/2.4.1-login-crash
Code language: JavaScript (javascript)

24. Gitflow with pull requests

Traditional Gitflow can be done with command-line merges, but modern teams should use pull requests or merge requests.

Recommended PR flow

flowchart TD
    A[feature/*] --> B[PR to develop]
    C[release/*] --> D[PR to main]
    C --> E[PR back to develop]
    F[hotfix/*] --> G[PR to main]
    F --> H[PR to develop]
Code language: CSS (css)

PR targets

25. Gitflow PR template

## Summary

Explain what changed.

## Branch type

- [ ] feature/*
- [ ] release/*
- [ ] hotfix/*
- [ ] support/*

## Target branch

- [ ] develop
- [ ] main
- [ ] release/*
- [ ] support/*

## Why

Explain the reason for this change.

## Changes

- Added:
- Changed:
- Fixed:
- Removed:

## Testing

- [ ] Unit tests
- [ ] Integration tests
- [ ] Regression tests
- [ ] Manual validation
- [ ] Staging validation

## Release impact

- Version:
- Release branch:
- Changelog updated:
- Migration required:

## Risk

Low / Medium / High

## Rollback plan

Explain how to revert, redeploy, or disable the change.

## Checklist

- [ ] CI passed
- [ ] Review completed
- [ ] No secrets committed
- [ ] Version updated if needed
- [ ] Release notes updated if needed
- [ ] Hotfix merged back to develop if needed
Code language: PHP (php)

26. Gitflow CI/CD design

Gitflow needs branch-aware CI/CD.

flowchart TD
    A[Branch pushed] --> B{Branch type?}
    B -- feature/* --> C[Run lint, unit tests, build]
    B -- develop --> D[Full CI + deploy integration/dev]
    B -- release/* --> E[Full regression + deploy staging/UAT]
    B -- main --> F[Build production artifact + tag release]
    B -- hotfix/* --> G[Critical CI + emergency validation]
    B -- support/* --> H[Version-specific tests]

Recommended pipeline behavior

27. Gitflow environment mapping

A common Gitflow environment mapping:

feature/*  → no deployment or ephemeral env
develop    → dev / integration
release/*  → staging / UAT
main       → production
hotfix/*   → emergency staging + production

flowchart LR
    A[feature/*] --> B[local / preview env]
    C[develop] --> D[dev / integration]
    E[release/*] --> F[staging / UAT]
    G[main] --> H[production]
    I[hotfix/*] --> J[emergency validation]
    J --> H
Code language: CSS (css)

28. Branch protection rules for Gitflow

Use branch protection to enforce Gitflow.

GitHub branch protection rules can require approving reviews and passing status checks before merging into protected branches. They can also control deletion, force pushes, and other requirements for important branches.

Recommended protections

main protection

- Require pull request
- Require status checks
- Require approval
- Require CODEOWNERS for critical files
- Block force push
- Block deletion
- Require signed tags or signed commits if needed
Code language: PHP (php)

29. CODEOWNERS for Gitflow

Example:

# Platform and CI/CD
/.github/workflows/ @devops-team
/infrastructure/ @platform-team

# Services
/services/auth/ @identity-team
/services/payment/ @payment-team
/services/notification/ @backend-team

# Security-sensitive areas
/security/ @security-team
/database/migrations/ @backend-leads @platform-team

# Release files
/VERSION @release-managers
/CHANGELOG.md @release-managers
Code language: PHP (php)

Recommended:

30. Gitflow release checklist

Before creating release branch:

- Planned features merged into develop
- CI passing on develop
- Known blockers reviewed
- Version number agreed
- Release owner assigned
- Release scope frozen

Before merging release into main:

- Regression testing complete
- Critical bugs fixed
- Version bumped
- Changelog updated
- Release notes ready
- Security scan passed
- Deployment plan ready
- Rollback plan ready
- Approval completed

After release:

- Tag pushed
- Production deployed
- Monitoring checked
- Release branch merged back to develop
- Release branch deleted or archived
- Release notes published

31. Gitflow hotfix checklist

Before hotfix:

- Production issue confirmed
- Severity agreed
- Correct production version identified
- Hotfix owner assigned
- Rollback path understood

During hotfix:

- Branch from main or production tag
- Fix only the production issue
- Run focused tests
- Open emergency PR
- Get required approval
Code language: JavaScript (javascript)

After hotfix:

- Merge into main
- Tag patch version
- Deploy production
- Validate recovery
- Merge into develop
- Merge into active release branch if needed
- Delete hotfix branch
- Create follow-up ticket

32. Gitflow with release candidates

For formal release cycles, release candidates are useful.

v2.4.0-rc.1
v2.4.0-rc.2
v2.4.0
Code language: CSS (css)

Flow:

flowchart TD
    A[release/2.4.0] --> B[tag v2.4.0-rc.1]
    B --> C[QA finds bug]
    C --> D[fix on release branch]
    D --> E[tag v2.4.0-rc.2]
    E --> F[QA approves]
    F --> G[merge to main]
    G --> H[tag v2.4.0]
Code language: CSS (css)

Commands:

git checkout release/2.4.0
git tag -a v2.4.0-rc.1 -m "Release candidate 1 for v2.4.0"
git push origin v2.4.0-rc.1
Code language: JavaScript (javascript)

Final release:

git checkout main
git merge --no-ff release/2.4.0
git tag -a v2.4.0 -m "Release v2.4.0"
git push origin main v2.4.0
Code language: JavaScript (javascript)

33. Gitflow and database migrations

Gitflow needs careful database migration discipline.

Dangerous pattern

feature branch changes schema
release branch stabilizes old app
hotfix needs production fix
develop expects new schema
production still has old schema
Code language: JavaScript (javascript)

Tiny mess. Giant headache.

Safe pattern: expand → migrate → contract

flowchart LR
    A[Expand schema] --> B[Deploy backward-compatible app]
    B --> C[Backfill data]
    C --> D[Switch reads/writes]
    D --> E[Contract old schema later]
Code language: CSS (css)

Rules

• Do not hide large migrations in feature branches.
• Release branches should receive only safe migration fixes.
• Destructive schema changes should be separated from feature rollout.
• Hotfixes should avoid schema changes unless absolutely necessary.
• develop, release/*, and main compatibility must be understood.

34. Gitflow with feature flags

Gitflow does not require feature flags, but feature flags make Gitflow safer.

Without flags:

unfinished feature stays in feature branch for weeks

With flags:

feature can merge into develop safely but remain disabled

flowchart TD
    A[feature branch] --> B[code behind flag]
    B --> C[merge to develop]
    C --> D[release branch]
    D --> E[deploy with flag off]
    E --> F[enable gradually]
Code language: CSS (css)

Feature flags are especially useful when:

• release scope changes
• a feature is code-complete but not business-ready
• risky behavior needs gradual rollout
• rollback should be instant
• QA wants selective enablement

35. Gitflow with multiple teams

Gitflow gets harder as team size grows.

Problems

Solutions

36. Gitflow for mobile apps

Gitflow fits mobile apps well because app releases often need QA, signing, approval, and staged rollout.

flowchart TD
    A[develop] --> B[release/mobile-5.1.0]
    B --> C[QA]
    C --> D[Signed build]
    D --> E[TestFlight / Internal testing]
    E --> F[App Store / Play Store approval]
    F --> G[Production rollout]
    G --> H[tag v5.1.0]
Code language: CSS (css)

Recommended branches:

main
develop
feature/*
release/ios-5.1.0
release/android-5.1.0
hotfix/*

Rules:

• Release branch is frozen except fixes.
• Version/build numbers are bumped in release branch.
• Tags must match shipped builds.
• Hotfixes may require app-store patch releases.
• Backend APIs must remain backward compatible for older app versions.

37. Gitflow for libraries and SDKs

Gitflow can fit libraries and SDKs because versions matter.

Recommended branches:

main
develop
feature/*
release/*
hotfix/*
support/*

Rules:

• Use Semantic Versioning.
• Tag every published package.
• Maintain support branches for old major versions.
• Breaking changes require a major version.
• Critical fixes may need backporting.

Example:

main → latest production release
develop → next release
support/2.x → v2 maintenance
support/1.x-lts → v1 long-term support

38. Gitflow for SaaS and web apps

Gitflow can be too heavy for fast web/SaaS teams.

Driessen’s 2020 reflection says web apps are often continuously delivered and usually do not need multiple versions of the software running in the wild; for such teams, he suggested a simpler workflow such as GitHub Flow instead of forcing Gitflow.

Use Gitflow for SaaS only when:

• releases are scheduled
• release approvals are mandatory
• customers need versioned releases
• staging/UAT is formal
• compliance requires release evidence
• multiple versions must be supported

Otherwise, GitHub Flow or trunk-based development is usually simpler.

39. Gitflow vs trunk-based development

Atlassian notes that Gitflow assigns specific roles to different branches, including feature, release, and hotfix branches, and is suited to scheduled release cycles.

40. Gitflow vs GitHub Flow

41. Gitflow pros and cons

Pros

Cons

42. When Gitflow is a good choice

Use Gitflow when you have:

• scheduled releases
• formal QA cycle
• versioned products
• mobile apps
• desktop apps
• firmware
• SDKs/libraries
• enterprise release approval
• multiple supported versions
• customer-specific release windows
• production hotfix requirements

AWS also positions Gitflow as suitable for teams with scheduled release cycles and a need to define a collection of features as a release.

43. When Gitflow is the wrong choice

Avoid Gitflow when:

• you deploy many times per day
• main is always deployable
• feature flags are mature
• CI/CD is fast and reliable
• releases are continuous
• you do not support old versions
• release branches create bureaucracy
• develop becomes unstable
• PRs sit for too long

For many web apps, Gitflow is like wearing a three-piece suit to eat instant noodles. Technically possible. Weird energy.

44. Gitflow anti-patterns

Anti-pattern 1: develop is always broken

Problem:

All features merge into develop, but CI is ignored.

Fix:

Protect develop.
Require CI.
Require review.
Keep develop releasable enough for integration.
Code language: PHP (php)

Anti-pattern 2: release branch accepts new features

Problem:

release/2.4.0 becomes feature playground

Fix:

Only fixes, version bump, release notes, and stabilization changes.

Anti-pattern 3: hotfix not merged back

Problem:

Production fixed in main.
Develop never receives fix.
Bug returns in next release.

Fix:

Every hotfix must merge into main and develop.
Also merge into active release branch if one exists.

Anti-pattern 4: feature branches live for months

Problem:

feature/new-platform lives forever
Code language: JavaScript (javascript)

Fix:

Split work.
Use feature flags.
Use branch by abstraction.
Merge smaller slices.
Code language: PHP (php)

Anti-pattern 5: too many release branches

Problem:

release/2.1
release/2.2
release/2.3
release/2.4
all active, all drifting

Fix:

Keep only necessary active release/support branches.
Archive/delete old release branches after tagging unless needed.
Code language: JavaScript (javascript)

45. Gitflow metrics

Measure Gitflow health.

46. Gitflow governance policy

Use this as a company standard.

Gitflow Policy

1. main represents production-ready code.
2. develop represents the next release integration branch.
3. feature branches start from develop and merge back into develop.
4. release branches start from develop and merge into main and develop.
5. hotfix branches start from main and merge into main and develop.
6. support branches exist only for maintained older versions.
7. main, develop, release/*, and support/* must be protected.
8. CI must pass before merge.
9. At least one review is required before merge.
10. Release branches accept only stabilization changes.
11. Hotfix branches accept only production emergency fixes.
12. Every production release must be tagged.
13. Hotfixes must be merged back to develop and active release branches.
14. Merged branches must be deleted unless they are support branches.
15. Release notes and changelog must be updated for releases.
Code language: JavaScript (javascript)

47. Gitflow branch protection policy

Recommended:

main:
  - no direct push
  - PR required
  - CI required
  - approval required
  - no force push
  - no deletion

develop:
  - no direct push
  - PR required
  - CI required
  - approval required

release/*:
  - PR required
  - release manager approval
  - full CI/regression required

hotfix/*:
  - emergency PR required
  - critical CI required
  - service owner approval

support/*:
  - PR required
  - compatibility tests required
  - maintainer approval

48. Gitflow release manager responsibilities

A release manager owns the release branch.

Responsibilities:

• decide release scope
• create release branch
• freeze new features
• coordinate QA
• approve release fixes
• ensure version bump
• ensure changelog
• ensure release notes
• merge release to main
• tag release
• merge release back to develop
• delete/archive release branch
• coordinate production deployment

49. Gitflow developer responsibilities

Developers should:

• branch from develop
• keep feature branches small
• rebase/merge from develop regularly
• write clear commits
• open PRs early
• respond to review
• add tests
• avoid mixing features
• avoid release branch changes unless fixing release bugs
• never push directly to main

50. Gitflow reviewer responsibilities

Reviewers should check:

• correct target branch
• small change scope
• test coverage
• backward compatibility
• release impact
• migration safety
• security impact
• rollback path
• changelog/version updates for release/hotfix
• hotfix back-merge path

51. Gitflow for DevOps/IaC repositories

Gitflow is usually not the best default for Terraform/IaC.

Why?

Infrastructure often benefits from:

main + feature branches + plan checks + environment workspaces/folders

Use Gitflow for IaC only when:

• releases of infrastructure modules are versioned
• consumers pin module versions
• release branches are genuinely needed
• old module versions are supported

For normal environment infrastructure repos, prefer:

main
feature/*
hotfix/*

with Terraform plan checks.

52. Gitflow for Kubernetes manifests

For Kubernetes GitOps, Gitflow is often too heavy.

Better structure:

main
feature/*

with directories:

environments/
  dev/
  staging/
  production/

Use release branches only when application release packaging requires stabilization.

53. Gitflow decision tree

flowchart TD
    A[Should we use Gitflow?] --> B{Do you have scheduled/versioned releases?}
    B -- No --> C[Prefer GitHub Flow or trunk-based]
    B -- Yes --> D{Do you need release stabilization branches?}
    D -- No --> E[Use release branch lite or GitLab Flow]
    D -- Yes --> F{Do you need hotfixes from production?}
    F -- Yes --> G[Gitflow is a good fit]
    F -- No --> H{Do you support old versions?}
    H -- Yes --> I[Gitflow + support branches]
    H -- No --> J[Gitflow or release branch model]
Code language: JavaScript (javascript)

54. Complete Gitflow example

Scenario:

Current production: v1.0.0
Next planned release: v1.1.0
Emergency hotfix: v1.0.1
Code language: CSS (css)

Initial state

main: v1.0.0
develop: next release work
Code language: CSS (css)

Feature work

git checkout develop
git checkout -b feature/add-reporting
git commit -m "feat(reporting): add export endpoint"
git push -u origin feature/add-reporting
Code language: JavaScript (javascript)

Merge to develop:

git checkout develop
git merge --no-ff feature/add-reporting
git push origin develop

Create release

git checkout develop
git checkout -b release/1.1.0
git push -u origin release/1.1.0

Fix release bug:

git commit -m "fix(reporting): correct CSV header order"
Code language: JavaScript (javascript)

Finish release:

git checkout main
git merge --no-ff release/1.1.0
git tag -a v1.1.0 -m "Release v1.1.0"
git push origin main v1.1.0

git checkout develop
git merge --no-ff release/1.1.0
git push origin develop
Code language: JavaScript (javascript)

Emergency hotfix

git checkout main
git checkout -b hotfix/1.1.1-login-crash
git commit -m "fix(auth): prevent crash on expired session"
Code language: JavaScript (javascript)

Finish hotfix:

git checkout main
git merge --no-ff hotfix/1.1.1-login-crash
git tag -a v1.1.1 -m "Hotfix v1.1.1"
git push origin main v1.1.1

git checkout develop
git merge --no-ff hotfix/1.1.1-login-crash
git push origin develop
Code language: JavaScript (javascript)

55. Gitflow visual summary

flowchart TD
    F[feature/*] --> D[develop]
    D --> R[release/*]
    R --> M[main]
    R --> D
    M --> H[hotfix/*]
    H --> M
    H --> D
    M --> T[version tag]
    S[support/* optional] --> ST[support tags]
Code language: CSS (css)

56. One-page Gitflow standard

Gitflow Standard

Permanent branches:
- main
- develop

Temporary branches:
- feature/*
- release/*
- hotfix/*

Optional long-term branches:
- support/*

Rules:
- feature/* starts from develop and merges into develop.
- release/* starts from develop and merges into main and develop.
- hotfix/* starts from main and merges into main and develop.
- support/* starts from release tag or maintained version line.
- main contains production-ready code only.
- develop contains next-release integration code.
- release branches allow bug fixes, version updates, and release notes only.
- hotfix branches allow urgent production fixes only.
- every production release is tagged.
- every hotfix is tagged.
- all protected branches require PR, CI, and review.

57. Final recommendation

Use Gitflow when the release process itself needs structure.

Gitflow is excellent for:

mobile apps
desktop apps
firmware
SDKs
libraries
enterprise products
scheduled releases
QA-heavy releases
multi-version support
regulated delivery

Avoid Gitflow when the team is better served by:

main + short-lived branches
continuous deployment
feature flags
fast CI/CD
trunk-based development
GitHub Flow

Final principle:

Gitflow is not a religion.
Gitflow is a release-management tool.

Use it when it matches the product’s release reality.

The best Gitflow implementation is not the one with the most branches.
It is the one where every branch has a clear purpose, every release is traceable, every hotfix returns to future development, and production can be repaired without stopping the whole team.

Rajesh Kumar

I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I have worked at Cotocus. I share tech blog at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow , and SEO strategies at Wizbrand.

Do you want to learn Quantum Computing?

Please find my social handles as below;

Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at WIZBRAND

Rajesh Kumar DailyLogs