Schematex
gitgraph·Mermaid gitGraph dialect·software, devops·complexity 3/3·since v0.8.0

Git Flow release history

A realistic Git Flow branch/merge/tag history — develop, a feature branch, a tagged release, and a hotfix merged back to both lines. Mermaid gitGraph syntax, rendered through Schematex's zero-dependency engine.

For the engineering lead documenting a workflow

Open in Playground →
gitgraph·§ —
↘ preview
100%
Git commit graph Git commit graph: 11 commits across 4 branches, 4 merges, orientation LR. main develop feature/login hotfix init scaffold feature scaffold login UI login API 1-49dec0f polish v1.0 2-2cadf25 patch CVE v1.0.1 3-2b38c3a 4-885cbfb
UTF-8 · LF · 22 lines · 476 chars✓ parsed·6.5 ms·9.5 KB SVG

What this shows

A full Git Flow release cycle, the branching strategy teams adopt to keep a clean trunk. Work forks off main into a long-lived develop, then into a short-lived feature/login branch; the feature merges back to develop, develop merges to main as the tagged v1.0 release. Then a security hotfix branches straight off main, lands a HIGHLIGHT commit, ships as v1.0.1, and is merged back down into develop so the fix isn't lost — the discipline that keeps the two lines from diverging.

The DSL is the Mermaid gitGraph dialect verbatim, so existing Mermaid sources port directly. The engine replays the operation list in order to assign each commit to a lane, routes the merge connectors from each branch tip without crossings, renders the patch commit emphasised as a HIGHLIGHT, and draws the version tags as flags — all from a KB-scale, dependency-free bundle.

Git graph syntax →