Jedes Projekt verweist auf ein Repository. Die Einstellungen dieses Repositories bestimmen, wie Coroid mit Ihrem Branch-Modell interagiert.
Sie finden sie unter den Einstellungen des Projekts.
Synchronisiert oder lokal nur
Der Repository-Modus bestimmt, ob Coroid auf GitHub oder GitLab schreiben darf.
- Synchronisiert (die Standardeinstellung): Coroid pusht den Branch jeder Aufgabe und öffnet Pull Requests gegen Ihren Basis-Branch.
- Lokal nur: Coroid klont das Repository und ruft Daten ab, schreibt aber nie darauf. Es gibt keine Pushes, keine Branches auf dem Remote-Server, keine Pull Requests, Kommentare, Reviews, Prüfläufe oder Webhooks, keine Merges und keine Pipeline-Läufe. Branches, Commits, Reviews, QA und Vorschauen finden alle innerhalb von Coroid statt.
Synchronisiert
- Daten aus GitHub abrufen
- Branches übertragen und Pull Requests öffnen
Nur lokal
- Daten aus GitHub abrufen
- Es werden weder Daten übertragen noch Kommentare hinzugefügt oder Pull Requests geöffnet.
- Die Branches werden direkt aus dem Git-System von Coroid abgerufen.
Wählen Sie den Modus beim Erstellen des Projekts aus und ändern Sie ihn unter den Einstellungen des Projekts. Ein Projekt im Modus „Lokal nur“ zeigt Lokal nur neben dem Repository-Namen an.
Der Modus „Lokal nur“ ist die sichere Möglichkeit, Coroid an einem echten Repository auszuprobieren. Aufgaben und Pläne laufen bis zur Überprüfung durch. Anstelle eines pull request wird die Überprüfung angezeigt. In Coroid gespeichert und eine Aktion: Synchronisierung starten. Zur Genehmigung ist ein synchronisiertes Projekt erforderlich, da die Genehmigung ein Merge in Ihren Basis-Branch bewirkt; innerhalb eines Plans werden die Aufgaben weiterhin auf dem Plan-Branch in Coroid zusammengeführt. Die Kopie Ihres Basis-Branches in Coroid bleibt identisch zum Remote-Branch – somit gelangt nichts dorthin, für das Sie kein pull request geöffnet haben.
Um die Arbeit auf Ihrem eigenen Rechner anzusehen, öffnen Sie Klonen und exportieren in den Repository-Einstellungen, erstellen Sie ein Zugriffstoken und holen Sie sich die Branches von Coroid über dessen Git ab:
git remote add coroid https://coroid@git.coroid.ai/git/<project-id>.git
git fetch coroidSynchronisierung starten schaltet das Projekt auf den Modus „Synchronisiert“. Ab dann werden neue Arbeiten gepusht und es werden Pull Requests erstellt. Arbeiten, die bereits in Coroid gespeichert sind, bleiben dort: Öffnen Sie dazu das pull request über die Überprüfungsseite (pull request für eine Aufgabe erstellen , pull request für einen Plan öffnen ). Der Wechsel zurück zum Modus „Lokal nur“ wirkt sich sofort aus.
Im Modus „Lokal nur“ hängt nichts davon ab, wie Ihr Token definiert ist: Coroid lehnt jedes Schreiben ins Repository ab – unabhängig von der möglichen Verbindung. Der Modus folgt den Branch-Einstellungen des Projekts in Einstellungs-Portabilität.
Basisbranch
Coroid arbeitet von Ihrem Basisbranch aus und öffnet Pull Requests zurück zu diesem Branch. Standardmäßig wird der Standardbranch des Repositories verwendet.
Ändern Sie ihn, wenn Sie an einem anderen Ort zusammenführen – etwa einen develop Branch, einen Release-Train oder einen langfristigen Integrations-Branch. Eine falsche Konfiguration ist der häufigste Fehler; dies führt dazu, dass Pull Requests einen Branch betreffen, der nicht überprüft wird.
Wenn sich der Zielbranch ändert
Ein Plan speichert den Commit des Basissbranches, von dem er startet. Falls sich der Basissbranch vor dem Zusammenführen des pull request des Plans ändert, hält Coroid das Zusammenführen zurück; siehe Wenn sich der Basissbranch bewegt. Diese Einstellung legt fest, was als Nächstes geschieht:
- Zur Überprüfung pausieren (Standard) – eine Person prüft die neuen Commits und stimmt ihnen entweder zu oder weist Coroid an, sie zusammenzuführen und erneut zu verifizieren.
- Zusammenführen und erneut verifizieren – Coroid führt die Änderungen in den Lane-Branch des Plans ein und startet anschließend erneut die Entwickler-, QA- und Review-Prozesse, ohne auf jemanden zu warten. Dabei werden Agentenstunden verbraucht. Sollte das Zusammenführen oder die erneute Verifizierung fehlschlagen, liegt die Entscheidung wieder bei einer Person.
In jedem Fall wird nichts zusammengeführt, bis der Plan gegen den aktuellen Basissbranch geprüft wurde oder eine Person die Abweichung akzeptiert hat. Die Einstellung gehört zu den Branch-Einstellungen des Projekts und wird daher mit diesen in Einstellungsportabilität.
Arbeitsbranches
Jede Aufgabe arbeitet in ihrem eigenen Branch. Für jede Aufgabe wird ein eigener Branch erstellt und bei Abschluss des Arbeitsumfangs gepusht (bei einem Projekt im Modus „lokal nur“ bleiben diese Branches in Coroid). So können zwei gleichzeitig laufende Aufgaben niemals denselben Branch nutzen und sehen auch nicht die jeweiligen laufenden Arbeiten des anderen.
Nichts wird jemals direkt in Ihren Basisbranch committet. Das ist keine Einstellung; es ist eine Eigenschaft der Funktionsweise von Coroid.
Ein Branch pro Aufgabe. Zwei Aufgaben teilen sich niemals einen Branch.
Ihre geforderten Reviews und Statusprüfungen bleiben unverändert.
Sie mergen ein main
Branch-Schutz
Ihr bestehender Branch-Schutz bleibt unverändert. Coroid öffnet einen gewöhnlichen Pull Request, sodass erforderliche Überprüfungen, Statusprüfungen und Einschränkungen für das Zusammenführen genauso funktionieren wie in Ihrem Team.
Falls Ihre Schutzregeln einen signierten Commit oder eine bestimmte Statusprüfung verlangen, die Coroid nicht bereitstellen kann, bleibt der pull request offen und lässt sich nicht zusammenführen – das zeigt, dass Ihre Regeln greifen und kein Fehler von Coroid vorliegt.
Aufräumen
Branches für abgeschlossene Arbeiten können nach dem Zusammenführen oder Schließen des pull request bereinigt werden. Falls Sie Branch-Namen für Audits oder Release-Tools nutzen, sollten Sie dies vor der Aktivierung prüfen.
Die Verbindung ändern
Falls sich die Verbindung zum zugrundeliegenden Repository ändert – ein rotierter Token, eine neu installierte App oder ein umbenannter Repository –, behält das Projekt seine Identität und seinen Verlauf bei. Weisen Sie es auf die neue Verbindung hin, anstatt ein neues Projekt zu erstellen, um Kontext, Einstellungen und vergangene Arbeit nicht zu verlieren.
Einstellungen der Release-Pipeline
Der Basis-Branch bestimmt den Ort, an dem Coroid Pull Requests öffnet. Die Bereitstellung erfolgt über ein separates Projekt. Release Konfiguration eines Releases: eine Umgebung, ihre Bereitschaftsrichtlinie sowie optional ein GitHub Actions- oder GitLab-Pipeline-Ref und ein Bereitstellungsjob. Das Ref muss auf den festgelegten Commit des Releases verweisen, bevor Coroid einen Ausführungsauftrag erteilt. Richten Sie eine umgebungsbezogene Callback-Anmeldeinformation ein, damit die Pipeline das Ergebnis melden kann; die Repository-Verbindung allein belegt nicht, was tatsächlich bereitgestellt wurde. Externe Pipelines können Ereignisse melden, ohne dass eine Auslösung durch Coroid erforderlich ist.