🌿 Mermaid

Git-graaf

Leg branchingstrategieën visueel uit

Open dit voorbeeld in de editor Genereer er een met AI

Wat is een Git-graaf?

Een git-graaf toont commits, branches, merges en tags. Het is de duidelijkste manier om je branchingstrategie te documenteren — git flow, trunk-based, release trains — voor het hele team.

Een git-graaf is lesmateriaal: hij hoort in CONTRIBUTING.md, in de onboardinggids, in de discussie over wel of niet squashen. Het is het enige diagram waarvan de syntaxis de commando’s weerspiegelt die de lezer straks typt, wat het makkelijk controleerbaar maakt. Met je repository heeft hij echter geen enkele verbinding — hij toont het branchingmodel dat je voor ogen hebt, nooit de geschiedenis die je werkelijk hebt. Van een remote weet hij niets: een fork teken je als een gewone branch.

Live voorbeeld

Mermaid-code

gitGraph
    commit id: "init"
    branch develop
    commit id: "setup CI"
    branch feature/auth
    commit id: "login page"
    commit id: "JWT"
    checkout develop
    merge feature/auth tag: "v0.2.0"
    checkout main
    merge develop tag: "v1.0.0"

Live voorbeeld

Wanneer gebruik je het

De branching- en releasestrategie van je team documenteren

Ontwikkelaars onboarden met visuele git-conventies

Hotfix- en releaseprocedures uitleggen

Veelgemaakte fouten

branch checkt ook uit

Na branch develop belandt elke volgende commit op develop en niet op main. Mensen voegen commits toe die ze op de trunk verwachten en vragen zich af waarom die baan leeg blijft — schrijf checkout main als je dat bedoelde.

De trunk heet main

checkout master faalt met “Trying to checkout branch which is not yet created”. Hernoem de standaardbranch met een init-directive die gitGraph.mainBranchName op master zet, op de eerste regel van het diagram.

cherry-pick vraagt een andere branch

De broncommit moet bestaan, moet de id dragen waarnaar je verwijst en moet op een andere branch staan. Cherry-picken vanaf de huidige branch faalt met “Source commit is already on current branch”.

Basissyntaxis

.mmd

gitGraph
    commit
    branch develop
    commit
    checkout main
    merge develop

gitGraph TB:
De standaardlay-out loopt van links naar rechts. Met TB: erachter wordt de graaf verticaal, wat een lange releasegeschiedenis veel beter op een documentatiepagina laat passen.
commit id: "hotfix" type: HIGHLIGHT tag: "v1.0.1"
Een commit neemt een id die je later kunt aanhalen, een type NORMAL, REVERSE of HIGHLIGHT, en een tag die als releaselabel op de baan wordt getekend.
branch develop order: 2 commit
branch maakt de branch aan én checkt hem in één stap uit. Het attribuut order legt de verticale positie van de baan vast, zodat main blijft waar lezers hem verwachten.
cherry-pick id: "fix-npe"
Cherry-pick kopieert één commit naar de huidige branch — de manier om een hotfix te tonen die naar een releasebranch is teruggezet, zonder de hele branch opnieuw te tekenen.

Vragen over dit diagram

Kan ik tags en releases tonen?

Ja — commits en merges accepteren een tag:-attribuut (bijv. tag: "v1.0.0"), perfect om releasepunten te documenteren.

Welke branchingstrategieën kan hij weergeven?

Allemaal: git flow, GitHub flow, trunk-based development, releasebranches — de syntaxis weerspiegelt echte git-operaties (branch, checkout, merge, cherry-pick).

Kan ik een git-graaf in CONTRIBUTING.md op GitHub zetten?

Ja — een codeblok met de taalaanduiding mermaid rendert in de bestandsweergave op GitHub en GitLab. Dat is zijn natuurlijke plek: de branchingregels en het plaatje ervan veranderen in dezelfde commit en dezelfde review. Reviewers krijgen een diff, geen nieuwe schermafbeelding.

Leest de git-graaf mijn echte repository?

Nee. Hij wordt met de hand geschreven en weet niets van je repo, dus hij loopt niet mee met je geschiedenis — en waarschuwt je niet als hij verouderd raakt. Behandel hem als een model van de branchingstrategie, niet als een log.

Hoe toon ik een rebase of een revert?

Een sleutelwoord voor rebase bestaat niet, dus teken het resultaat: de commits opnieuw getekend op de doelbranch. Een revert is commit type: REVERSE, die de commit doorgestreept op zijn baan rendert, zodat de lezer ziet dat hij is teruggedraaid.

Kan een git-graaf datums of een releaseplanning tonen?

Nee. Commits hebben wel een volgorde maar geen tijdstempels, en er is geen as. Combineer de graaf met een tijdlijn voor releasedatums, of met een Gantt-grafiek als de release train duren en afhankelijkheden heeft die planning verdienen.

Git-graaf of een ander diagramtype?

Git-graaf of tijdlijn?

Beide zijn chronologisch. Een git-graaf is chronologisch én vertakt: hij laat werk op parallelle banen zien dat weer samenkomt. Een tijdlijn is chronologisch en vlak. Gaat het erom dat twee stromen uiteenliepen, dan maakt alleen de git-graaf dat zichtbaar.

Git-graaf of flowchart?

Gebruik een git-graaf om te tonen hoe de geschiedenis eruitziet, en een flowchart om te tonen wat een ontwikkelaar moet doen. “Branch vanaf main, open een PR, squash-merge” is een procedure met beslissingen erin, en dus een flowchart die een git-graaf illustreert.

Verken de andere diagramtypen

🔀 Flowchart 💬 Sequentiediagram 🧩 Klassediagram 🗄️ Entiteit-relatiediagram 🔄 Toestandsdiagram 📅 Gantt-grafiek 🥧 Cirkeldiagram 🧠 Mindmap 🕰️ Tijdlijn 🚶 User journey 🎯 Kwadrantgrafiek

Maak nu je Git-graaf

Beschrijf het in gewone taal — de AI schrijft de Mermaid-code voor je.

Mermaid Studio openen