Git-Graph
Erklären Sie Branching-Strategien visuell
Was ist ein Git-Graph?
Ein Git-Graph zeigt Commits, Branches, Merges und Tags. Er ist der klarste Weg, Ihre Branching-Strategie zu dokumentieren — git flow, Trunk-based, Release Trains — für das ganze Team.
Ein Git-Graph ist Lehrmaterial: Er gehört in CONTRIBUTING.md, in den Onboarding-Guide, in die Diskussion darüber, ob squasht wird. Er ist das einzige Diagramm, dessen Syntax die Befehle spiegelt, die der Leser tippen wird — das macht ihn leicht überprüfbar. Mit Ihrem Repository hat er allerdings keine Verbindung: Er zeigt das Branching-Modell, das Sie anstreben, nie die Historie, die Sie tatsächlich haben. Ein Konzept für Remotes kennt er nicht, ein Fork muss also als gewöhnlicher Branch gezeichnet werden.
Live-Beispiel
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"Wann einsetzen
Häufige Fehler
branch checkt auch aus
Nach branch develop landet jeder folgende Commit auf develop statt auf main. Man fügt Commits hinzu, erwartet sie auf dem Trunk und wundert sich über dessen leere Spur — schreiben Sie vorher checkout main, wenn Sie das meinten.
Der Trunk heißt main
checkout master scheitert mit „Trying to checkout branch which is not yet created“. Benennen Sie den Standard über eine init-Direktive um, die gitGraph.mainBranchName in der ersten Zeile des Diagramms auf master setzt.
cherry-pick braucht einen anderen Branch
Der Quell-Commit muss existieren, die referenzierte ID tragen und auf einem anderen Branch liegen. Ein Cherry-Pick vom aktuellen Branch scheitert mit „Source commit is already on current branch“. Legen Sie den Hotfix zuerst auf einem eigenen Branch an.
Grundlegende Syntax
gitGraph
commit
branch develop
commit
checkout main
merge developgitGraph TB:Standardmäßig läuft der Graph von links nach rechts. Mit TB: wird er senkrecht, was eine lange Release-Historie deutlich besser auf eine Dokumentationsseite bringt.
commit id: "hotfix" type: HIGHLIGHT tag: "v1.0.1"Ein Commit nimmt eine ID, auf die Sie sich später beziehen können, einen type von NORMAL, REVERSE oder HIGHLIGHT und ein tag, das als Release-Label auf der Spur gezeichnet wird.
branch develop order: 2 commitbranch legt den Branch an und checkt ihn in einem Schritt aus. Das Attribut order fixiert die vertikale Position der Spur, sodass main dort bleibt, wo Leser sie erwarten.
cherry-pick id: "fix-npe"Cherry-Pick kopiert einen Commit auf den aktuellen Branch — so zeigen Sie einen in eine Release-Linie zurückportierten Hotfix, ohne den ganzen Branch neu zu zeichnen.
Fragen zu diesem Diagramm
Kann ich Tags und Releases zeigen?
Ja — Commits und Merges akzeptieren ein tag:-Attribut (z. B. tag: "v1.0.0"), perfekt zur Dokumentation von Release-Punkten.
Welche Branching-Strategien kann er darstellen?
Alle: git flow, GitHub flow, Trunk-based Development, Release-Branches — die Syntax spiegelt echte Git-Operationen wider (branch, checkout, merge, cherry-pick).
Kann ich einen Git-Graph in die CONTRIBUTING.md auf GitHub legen?
Ja — ein Codeblock mit der Auszeichnung mermaid wird in der Dateiansicht von GitHub und GitLab gerendert. Das ist sein natürlicher Ort: Die Branching-Regeln und ihr Bild ändern sich im selben Commit und im selben Review. Reviewer bekommen einen Diff, keinen neuen Screenshot.
Liest der Git-Graph mein echtes Repository aus?
Nein. Er wird von Hand geschrieben und weiß nichts über Ihr Repository. Er läuft Ihrer Historie deshalb nicht hinterher — warnt Sie aber auch nicht, wenn er falsch wird. Behandeln Sie ihn als Modell der Branching-Strategie, nicht als Log.
Wie stelle ich ein Rebase oder ein Revert dar?
Ein Schlüsselwort für Rebase gibt es nicht, zeichnen Sie also das Ergebnis: die Commits, neu auf dem Zielbranch. Ein Revert ist commit type: REVERSE, was den Commit durchgestrichen auf seiner Spur zeigt, damit der Leser die Rücknahme sieht.
Kann ein Git-Graph Datumsangaben oder einen Release-Plan zeigen?
Nein. Commits sind geordnet, tragen aber keine Zeitstempel, und eine Achse gibt es nicht. Kombinieren Sie den Graphen für Release-Termine mit einer Zeitleiste oder mit einem Gantt-Diagramm, wenn der Release-Train Dauern und Abhängigkeiten hat.
Git-Graph oder ein anderer Diagrammtyp?
Git-Graph oder Zeitleiste?
Beide sind chronologisch. Ein Git-Graph ist chronologisch und verzweigt: Er zeigt Arbeit auf parallelen Spuren, die wieder zusammenläuft. Eine Zeitleiste ist chronologisch und flach. Geht es gerade darum, dass zwei Stränge auseinandergelaufen sind, macht nur der Git-Graph das sichtbar.
Git-Graph oder Flowchart?
Der Git-Graph zeigt, wie die Historie aussieht, das Flowchart, was ein Entwickler tun soll. „Von main abzweigen, PR öffnen, per Squash mergen“ ist eine Prozedur mit Entscheidungen darin — also ein Flowchart, das ein Git-Graph daneben illustriert.
Erstellen Sie jetzt Ihr Git-Graph
Beschreiben Sie es in natürlicher Sprache — die KI schreibt den Mermaid-Code für Sie.
Mermaid Studio öffnen