Muss jemand den Code-Graph pflegen?

Nein. Er leitet sich vollständig aus Git und der Pipeline ab — Branch-Snapshots und Merge-Walks aus deiner CI. Niemand sortiert hier Karten oder trägt Versionen nach.

Sehe ich fremde, private Boards?

Nein. Die Sichtbarkeit der Gruppe gilt auch hier — bis hinunter zu den Zählungen.

Welche Git-Hoster funktionieren?

Jeder, dessen CI die Snapshot- und Merge-Feeds bedienen kann — es sind einfache HTTP-Aufrufe, kein Anbieter-Plugin.

Warum ist „nie gemergt„ bei mir leer?

Weil dieses Signal keine Vergangenheit haben kann: Ein Branch, der ohne Merge gelöscht wurde, hinterlässt in Git keine Spur. Beobachtet wird ab dem ersten Snapshot — die Seite sagt das selbst, statt zu behaupten, es sei nie etwas verworfen worden.

Code-Graph lesen: was ohne Ticket live ging

Jedes Werkzeug zeigt, was geplant war. Der Code-Graph zeigt, was passiert ist — inklusive der Lücke dazwischen: Commits, die produktiv gingen, ohne je eine Karte zu nennen. Er gehört zum Developer-Plan.

Was du brauchst

Den Developer-Plan — siehe Preise.
Eingerichtetes Git: Commit-Verknüpfung und getaggte Releases — der Graph speist sich aus beidem.

1. Voraussetzungen prüfen

Der wichtigste Satz zuerst: Hier pflegt niemand etwas von Hand. Die Seite leitet sich aus Git und deiner CI ab — Branch-Snapshots und Merge-Walks. Was du siehst, ist abgeleitet, nicht kuratiert.

2. Die Seite öffnen

Der Code-Graph lebt pro Gruppe, neben Boards und Backlog — dieselbe Sichtbarkeit wie alles andere in der Gruppe, bis hinunter zu den Zählungen.

3. Die Release-Spine lesen

Das Rückgrat: jedes veröffentlichte Release ein Band auf der Zeitachse, mit seinen Karten, Commits und PRs. „Wann ging das live?" ist damit eine Blick-Frage, keine Recherche.

4. Offene Branches sehen

Darüber das Laufende: offene Branches, wovon sie abzweigen, wie weit sie voraus sind, welche Karte dazugehört. Ein Branch, der seit drei Wochen offen ist und von einem uralten Stand abzweigt, fällt hier auf — bevor der Merge wehtut.

5. Gemergt, aber nicht veröffentlicht

Der Zwischenraum, den die meisten Werkzeuge verschlucken: gelandet, aber in keinem Release. Das ist die Antwort auf „ist das schon draußen?" — gemergt heißt eben noch nicht veröffentlicht.

6. Die Liste ohne Ticket lesen

Und die Liste, für die es diese Seite gibt: Commits, die produktiv gingen und keine Karte nennen. Kein Vorwurf — ein Befund. Manches davon ist der Hotfix von Samstagnacht, manches die Konfigurationsänderung, von der niemand mehr weiß. Der Graph macht sichtbar, worüber das Board schweigt.

Eine Ehrlichkeit gehört dazu: Ein Branch, der ohne Merge gelöscht wurde, hinterlässt in Git keine Spur — dieses Signal kann erst ab dem ersten Snapshot sammeln, und die Seite sagt genau das, statt zu behaupten, es sei nie etwas verworfen worden.

Wenn es nicht klappt

Die Seite ist leer. Es fehlen die Feeds: Commit-Verknüpfung einrichten, Releases taggen, Snapshot-Feed aus der CI bedienen.
Ein Release fehlt als Band. Es wurde nie veröffentlicht — geplante Releases sind keine Bänder.
„Nie gemergt„ bleibt leer. Kein Fehler — siehe oben: Das Signal beginnt mit dem ersten Snapshot.

Nächste Schritte

Der Code-Graph — die Feature-Seite mit dem Gesamtbild.
Ein Release an einen Git-Tag binden.
Projektmanagement für Entwickler.