Dokumentation · Ablauf
Welche Lauf-Branches warten darauf, in die Basis zu kommen — mergen, nachziehen, verwerfen, und was ein Konflikt kostet.
Branches und Konflikte
Jeder Lauf arbeitet auf einem eigenen Branch. Fertig heisst deshalb noch nicht im Repository: die Arbeit wartet, bis jemand sie in die Basis übernimmt. Diese Seite zeigt, welche Lauf-Branches warten — und lässt dich entscheiden.
Ein Merge ist eine Entscheidung über das Repository, nicht über ein Ticket. Deshalb liegt sie bei dir und passiert nie von selbst.
Alle Bildschirmfotos zeigen eine Demo-Umgebung mit Beispieldaten.
Was du siehst
Die Seite listet je Projekt die offenen Lauf-Branches, dazu die Basis — der Branch, in den alles zurückfliesst. Zu jedem Branch steht, wie sein Lauf ausging: abgeschlossen, gescheitert, abgebrochen, oder „Ausgang unbekannt”, wenn kein Lauf dazu im Trail steht. Der letzte Fall ist kein Fehler, aber ein Grund zur Vorsicht: der Branch könnte ungemergte Arbeit tragen, deshalb bietet die Seite dort keine Aktion an.
Steht „wird gerade bearbeitet”, ruhen die Aktionen. Das ist Absicht: ein Lauf pusht auf genau diesen Branch, und ein Merge würde ihm den Boden unter den Füssen wegziehen.
Eine Meldung, die du ernst nehmen musst: „Die Branch-Sicht konnte NICHT gelesen werden.” Das heisst nicht „alles gemergt” — es heisst, dass wir nichts wissen. Häufigster Grund ist ein Zugriffsfehler (403): das Repository ist da, der Zugang darf nicht hineinsehen. Dann fehlt der Verbindung meist das Recht Pull requests: Read.
Die Aktionen
| Aktion | Was sie tut |
|---|---|
| Mergen | Übernimmt den Branch in die Basis — nur, wenn der Hoster das ohne Konflikt kann. Auf Wunsch wird der Branch danach gelöscht. |
| Auf Stand bringen | Zieht die Basis in den Branch nach. Die Basis bewegt sich dabei nicht. Wer nur veraltet war, wird dadurch mergebar. |
| Alle auf Stand bringen | Dasselbe für jeden offenen Lauf-Branch des Projekts. Die Meldung sagt danach, wie viele mergebar wurden und wie viele einen Konflikt haben. |
| Verwerfen | Löscht den Branch. Die Arbeit dieses Laufs ist danach nur noch im Audit-Trail nachvollziehbar. |
| Zustand abgleichen | Trägt Merges nach, die direkt beim Hoster gemacht wurden. Die Liste liest ohnehin live — der Audit-Trail nicht. |
Wenn es einen Konflikt gibt
Zwei Wege, und der Unterschied zwischen ihnen ist Geld:
„Konflikte ansehen” — rein lesend, kein Lauf, kein Modell. Zeigt jede Konfliktstelle mit beiden Seiten nebeneinander: unsere Seite (der Lauf-Branch) und ihre Seite (die Basis). Du kannst je Stelle eine Seite nehmen oder für die ganze Datei entscheiden. Das kostet nichts.
„Konflikt auflösen (Lauf)” — startet einen echten Lauf. Die Basis wird eingemergt, je Konfliktdatei entsteht ein Slice, danach wird gebaut und getestet. Das kostet Tokens und erscheint in der Lauf-Liste. Der richtige Weg, wenn die Auflösung fachlich entschieden werden muss statt nur „links oder rechts”.
Solange ein Konflikt-Lauf arbeitet, warten die übrigen Branches desselben Projekts. Auch das ist Absicht: bewegte sich die Basis währenddessen, wäre die eben aufgelöste Stelle sofort wieder strittig — und der nächste Konflikt träfe genau diesen Branch.
Wenn nichts angeboten wird
- „Für dieses Projekt gibt es (noch) kein Repository beim Hoster.” — der erste Lauf hat noch nichts angelegt.
- „Kein Hoster verdrahtet.” — die Fabrik pusht für dieses Projekt nirgendwohin; verbinde zuerst einen Code-Host (s. Repositories verbinden).
- „Kein offener Lauf-Branch.” — alles gemergt.