Git Branching Strategy and GitFlow

A Git branching strategy defines how a team creates, uses, merges, and manages branches. GitFlow is one specific branching strategy that uses dedicated branches for development, features, releases, and production fixes.

1. What is a Git Branching Strategy, and Why Is It Needed?

What is it?

A Git branching strategy is a set of rules a development team follows for managing Git branches during software development.

It defines things such as:

Which branches should exist
Where developers create feature branches from
Where feature branches are merged
How releases are prepared
How production bugs are fixed
Which branches represent production-ready code

For example:

main
 |
 +---- develop
        |
        +---- feature/login
        |
        +---- feature/payment

Instead of every developer creating and merging branches differently, the team follows the same workflow.

Why Do We Need a Branching Strategy?

Imagine five developers working on different features:

Developer A → Login
Developer B → Payment
Developer C → Reports
Developer D → Registration
Developer E → Notifications

If everyone directly changes main, managing releases and unfinished work becomes difficult.

With a branching strategy:

main
 |
 +--- develop
       |
       +--- feature/login
       |
       +--- feature/payment
       |
       +--- feature/reports

Developers can work independently and integrate changes through a controlled process.

A branching strategy helps with:

Parallel development
Code isolation
Pull Request workflows
Code reviews
Release management
Production hotfixes
Protecting main
CI/CD automation

Simple Example

Create a feature branch:

git switch develop
git pull origin develop

git switch -c feature/login

Develop the feature:

git add .
git commit -m "Add login feature"
git push -u origin feature/login

Then create a Pull Request:

feature/login
      |
      | PR
      v
   develop

The feature is reviewed and merged without directly modifying the production branch.

2. What is GitFlow?

What is it?

GitFlow is a branching model that defines specific branches for production, development, features, releases, and hotfixes.

The two long-lived branches are typically:

main
develop

Temporary supporting branches include:

feature/*
release/*
hotfix/*

The overall structure is:

main
 |
 +-------------------------------+
                                  |
develop --------------------------+
   |
   +--- feature/login
   |
   +--- feature/payment
   |
   +--- release/1.0
                                  |
main -----------------------------+
   |
   +--- hotfix/1.0.1

3. GitFlow Branches

Branch	Purpose	Usually Created From	Usually Merged Into
`main`	Production-ready code	—	—
`develop`	Integration for upcoming development	`main` initially	—
`feature/*`	Develop individual features	`develop`	`develop`
`release/*`	Prepare a release	`develop`	`main` and `develop`
`hotfix/*`	Urgent production fix	`main`	`main` and `develop`

The most important point to remember is:

Feature → develop
Release → main + develop
Hotfix  → main + develop

4. `main` Branch

main represents production-ready code.

main

A---B---C

Each release may also be tagged:

A---B---C
        |
      v1.0.0

For example:

git tag v1.0.0
git push origin v1.0.0

Normally developers should not directly develop features on main.

5. `develop` Branch

develop is the integration branch for the next release.

main
 |
 A
  \
   B---C---D    develop

Developers normally create feature branches from develop.

For example:

git switch develop
git pull origin develop

git switch -c feature/login

6. Feature Branch

A feature branch is used to develop a new feature independently.

Example:

feature/login
feature/payment
feature/reporting

Create it from develop:

git switch develop
git switch -c feature/login

Development happens:

develop

A---B
     \
      C---D---E
          feature/login

After completion:

feature/login
      |
      | Pull Request
      v
   develop

Then the feature branch can usually be deleted.

7. Release Branch

When the team is ready to prepare a new production release, a release branch is created from develop.

For example:

git switch develop
git switch -c release/1.0

Flow:

develop
   |
   +------ release/1.0

The release branch is generally used for final preparation such as:

Bug fixes
Version updates
Release configuration
Final testing

Normally, major new feature development should not be added to the release branch.

After the release is ready:

release/1.0
    |
    +------> main
    |
    +------> develop

It is merged into both main and develop so that release-specific fixes are retained in future development.

The production commit can then be tagged:

git tag v1.0.0

8. Hotfix Branch

Suppose version 1.0.0 is running in production and a critical bug is discovered.

You should not wait for unfinished work in develop.

Create a hotfix directly from main:

git switch main
git pull origin main

git switch -c hotfix/1.0.1

Flow:

                  develop
                     |
                     |
main ---- v1.0.0 ----+
   \
    \
     hotfix/1.0.1

Fix the issue:

git add .
git commit -m "Fix login production issue"

After testing, the hotfix goes into:

hotfix/1.0.1
      |
      +------> main
      |
      +------> develop

The updated production version might then be tagged:

git tag v1.0.1

Why merge it back into develop?

Because otherwise future releases could lose the production fix.

9. Complete GitFlow

A simplified GitFlow lifecycle looks like this:

                    feature/login
                   /             \
develop -----------+---------------+-------- release/1.0
                                              |       |
                                              |       |
main -----------------------------------------+-------+---- v1.0
                                                       \
                                                        hotfix/1.0.1
                                                        /           \
main --------------------------------------------------+-------------+-- v1.0.1
                                                                       \
develop <---------------------------------------------------------------+

Conceptually:

main
 |
 | production
 |
 +--------------------------------+
                                  |
develop                           |
 |                                |
 +--> feature/login               |
 |        |                       |
 |        +----> develop          |
 |                                |
 +--> feature/payment             |
 |        |                       |
 |        +----> develop          |
 |                                |
 +--> release/1.0 ----------------+---> main
          |
          +---------------------------> develop

main
 |
 +--> hotfix/1.0.1
          |
          +---------------------------> main
          |
          +---------------------------> develop

10. Practical Team Example

Suppose your team is developing an e-commerce application.

Current production:

main → v1.0

Upcoming version:

develop → v2.0 development

Developers work independently:

Developer A
    |
    +--> feature/login

Developer B
    |
    +--> feature/payment

Developer C
    |
    +--> feature/reports

After completion:

feature/login -----\
feature/payment ----> develop
feature/reports ---/

When version 2.0 is ready:

develop
   |
   v
release/2.0
   |
   +----> main → v2.0
   |
   +----> develop

If production then has an urgent bug:

main
 |
 +--> hotfix/2.0.1
          |
          +----> main → v2.0.1
          |
          +----> develop

11. Why Use GitFlow?

Advantages

Clear separation between development and production.
Supports multiple developers working simultaneously.
Dedicated release preparation.
Clear process for production hotfixes.
Useful when releases happen on planned schedules.
Production code remains isolated from unfinished development.

Disadvantages

GitFlow can be more complicated than necessary for teams practicing frequent deployment or continuous delivery.

It introduces several branch types:

main
develop
feature/*
release/*
hotfix/*

That means more:

Branch management
Merges
Pull Requests
Potential merge conflicts

Teams using continuous delivery often choose simpler strategies such as GitHub Flow or trunk-based development.

12. GitFlow vs Simple Feature Branch Workflow

GitFlow	Simple Feature Branch Workflow
Uses `main` and `develop`	Often primarily uses `main`
Uses feature branches	Uses feature branches
Dedicated release branches	May not use release branches
Dedicated hotfix branches	Fixes can use normal short-lived branches
More structured	Simpler
More branch management	Less branch management
Well suited to structured/versioned release cycles	Often suited to frequent delivery

13. Key Points