Tutorial
Code-Graph lesen: was ohne Ticket live ging
Releases als Bänder, offene Branches und die Commits, die produktiv gingen, ohne je eine Karte zu nennen. So liest du den Code-Graph.
Zuletzt aktualisiert:
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, sondern 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.
Häufige Fragen
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.
Welcher Plan?
Der Developer-Plan.