MermanDraw
Open Editor

Mermaid exampleGit Graph

Git Branching Strategy as a Mermaid Git Graph

A git graph shows how branches split and rejoin over time. Teams draw one when they adopt or change a branching model, because the picture settles arguments that a paragraph of rules never does: where features start, where releases are cut, and where hotfixes land.

  • git branching diagram
  • gitflow diagram
  • mermaid gitgraph
  • git flow example
  • branching strategy
Git Branching Strategy as a Mermaid Git Graphmaindevelopfeature/searchrelease/1.1hotfix/loginv1.0setupsearch apisearch uibump 1.1v1.1fix loginv1.1.1
Open in editor → 23 linesrenders in GitHub, Notion, Obsidian

Mermaid code

gitGraph
    commit id: "v1.0"
    branch develop
    checkout develop
    commit id: "setup"
    branch feature/search
    checkout feature/search
    commit id: "search api"
    commit id: "search ui"
    checkout develop
    merge feature/search
    branch release/1.1
    checkout release/1.1
    commit id: "bump 1.1"
    checkout main
    merge release/1.1 tag: "v1.1"
    checkout develop
    merge release/1.1
    checkout main
    branch hotfix/login
    commit id: "fix login"
    checkout main
    merge hotfix/login tag: "v1.1.1"

Paste this into any tool that renders Mermaid, or into the editor to change the theme and export PNG or SVG. Syntax reference: Git Graph guide.

What this diagram shows

This graph follows a classic release-branch model. develop carries day-to-day work. feature/search branches from it and merges back. release/1.1 is cut from develop, receives a version bump, and merges into main with a v1.1 tag and back into develop. The hotfix/login branch comes off main and merges back with a v1.1.1 tag.

Mermaid draws the graph from the sequence of commit, branch, checkout, and merge commands, so the source reads like a shell history. That makes it easy to keep in a CONTRIBUTING file next to the written rules.

How to adapt it

  • For trunk-based development, delete the develop and release/1.1 lines and branch every feature directly from main.
  • Rename feature/search and hotfix/login to your branch naming convention, for example feat/JIRA-123.
  • Add tag: "..." to any merge into main that produces a deployable version.
  • Insert more commit id: "..." lines on develop between merges to show that other work landed in parallel.
  • Add %%{init: {"gitGraph": {"mainBranchName": "master"}}}%% on the first line if your default branch is not called main.

FAQ

Why does the hotfix merge into main but not back into develop here?

To keep the example short. In practice add checkout develop and merge hotfix/login after the main merge, otherwise the fix is lost at the next release. Most branching models require that back-merge.

Can I control which commit a branch starts from?

A branch command always starts from the current checked-out commit. Run checkout on the branch you want as the parent first, then branch. There is no way to branch from an older commit retroactively.

How do I show a squash merge or a cherry-pick?

Use merge feature/search type: HIGHLIGHT to emphasize a merge, and cherry-pick id: "search ui" to copy a commit onto the current branch. Both need the referenced commit ids to exist.