---
titel: "Branches und Konflikte"
adresse: https://docs.anvil-coder.tech/docs/branches
beschreibung: "Welche Lauf-Branches warten darauf, in die Basis zu kommen — mergen, nachziehen, verwerfen, und was ein Konflikt kostet."
sprache: de
---

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](https://docs.anvil-coder.tech/docs/repos-verbinden)).

- **„Kein offener Lauf-Branch.”** — alles gemergt.