Git Branch Strategy: Mermaid Flowchart

About Source

A Git branch strategy establishes a set of long-lived and short-lived branch types with defined rules about what gets merged where — enabling parallel development, stable releases, and rapid hotfixes without conflicts.

How the strategy works

The strategy is built around two long-lived branches: main (or master) and develop. The main branch always reflects production-ready code; it is never committed to directly. The develop branch serves as the integration target for all completed features.

Feature branches are created from develop and named after the issue or ticket they address. When a feature is complete and passes review (see Pull Request Workflow), it is merged back into develop. Feature branches are ephemeral and deleted after merging.

Release branches are cut from develop when the team is ready to stabilize a release. Only bug fixes are committed to a release branch — no new features. Once the release is stable and tested, it is merged into both main and develop to keep both branches in sync. A version tag is applied to main.

Hotfix branches are created directly from main when a critical production bug must be patched immediately. After fixing, the hotfix is merged into both main and develop (or the active release branch), ensuring the fix is not lost in future releases.

This strategy, popularized as Gitflow, provides a clear structure for teams shipping regular versioned releases. Teams shipping continuously may prefer a simplified trunk-based model represented by the Git Workflow diagram.

Frequently asked questions

A Git branch strategy defines the types of branches a team uses — such as feature, release, and hotfix — and the rules for what gets merged where. It keeps parallel development organised and ensures production-ready code is never accidentally overwritten.

Gitflow uses two permanent branches: `main` (always production-ready) and `develop` (integration target). Features branch from `develop` and merge back; releases branch from `develop` for stabilisation and merge into both `main` and `develop`; hotfixes branch from `main` and merge into both.

Gitflow suits teams shipping periodic versioned releases; it provides clear isolation between features, releases, and hotfixes. Trunk-based development suits continuous-delivery teams that deploy many times per day; it minimises merge conflicts by keeping branches very short-lived and merging to `main` frequently.

Use Gitflow when you maintain multiple concurrent release versions or need extended stabilisation periods before shipping. Use trunk-based development when your team deploys continuously and relies on feature flags to hide incomplete work rather than long-running branches.

mermaid

flowchart TD
    Main[main branch] -->|cut hotfix| Hotfix[hotfix branch]
    Hotfix -->|bug fixed| MergeHotfixMain[Merge into main]
    Hotfix -->|sync fix| MergeHotfixDev[Merge into develop]
    MergeHotfixMain --> TagMain[Tag release on main]

    Main -->|cut release| Release[release branch]
    Release -->|stabilize| BugfixRelease[Commit bug fixes only]
    BugfixRelease --> MergeRelMain[Merge into main]
    BugfixRelease --> MergeRelDev[Merge into develop]
    MergeRelMain --> TagRelease[Tag version on main]

    Develop[develop branch] -->|cut feature| Feature[feature branch]
    Feature -->|implement| Commits[Commit feature work]
    Commits -->|PR approved| MergeFeature[Merge into develop]
    MergeFeature --> Develop
    Develop -->|ready for release| Release