Ihre erste Distribution ausrollen
Ihre erste Distribution durchführen
Ihre erste Distribution ausrollen
Sobald die lokalen Checks bestanden sind, folgt der erste echte Rollout.
Wenn divekit doctor oder divekit dev noch ernsthafte Probleme melden, beheben Sie diese zuerst.
Sieht Ihr Setup bereits klar aus und arbeiten Sie in einer sicheren Ziel-Gruppe, kann es losgehen.
Mitglieder bereitstellen
Verteilte Repositories gehören in der Regel Personen. Divekit bietet Ihnen zwei interaktive Wege, sie bereitzustellen:
- Vor dem Rollout mit
divekit members: ein interaktiver Prompt, in dem Sie Ihre Mitglieder-Eingabe machen. Neue Eingaben werden mit den bereits konfigurierten Mitgliedern zusammengeführt. - Während des Rollouts: Wenn noch keine Mitglieder konfiguriert sind, öffnet
divekit distributedieselbe interaktive Mitglieder-Eingabe, bevor es irgendetwas anlegt.
In beiden Fällen speichert Divekit die Mitglieder-Eingabe als Datei mit Zeitstempel in Ihrem Divekit-Verzeichnis auf Benutzerebene (~/.divekit/members/) — nicht im Projekt — und referenziert sie aus config.json über einen members.path-Eintrag wie $DIVEKIT_MEMBERS/2026-07-16_10-24-55_M0_members.json. Die Berechtigungsstufe kommt aus members.permissions in config.json.
Die Mitglieder-Eingabe entscheidet auch, wie viele Repositories entstehen: Jede Zeile wird zu einer Gruppe, und jede Gruppe bekommt genau ein generiertes Repository. Zwei Zeilen erzeugen also zwei Repositories.
Eine Zeile mit mehreren kommagetrennten Accounts, etwa alice,bob, bildet ein Team, das sich ein Repository teilt. Verwenden Sie reine GitLab-Benutzernamen — kein @-Präfix, keine E-Mail-Adressen.
Wenn Sie bereits eine Mitgliederliste als Datei haben, überspringt divekit distribute --members-file <pfad> die interaktive Mitglieder-Eingabe. Sind zusätzlich schon Mitglieder konfiguriert, fragt Divekit trotzdem zuerst, was damit passieren soll.
Halten Sie diese Datei außerhalb des Projektordners: Alles im Projekt wird verteilt — eine Mitgliederliste im Projektwurzelverzeichnis würde also in jedem generierten Repository landen.
Für diesen ersten Rollout brauchen Sie keine echte Kursliste: Zwei Zeilen mit einem sicheren Test-Account reichen und geben Ihnen zwei Repositories zum Vergleichen.
Wenn Sie beim lokalen Validierungslauf bereits Mitglieder eingegeben haben, sind diese noch konfiguriert — der Rollout wird anbieten, sie zu behalten.
Die konfigurierten Mitglieder können Sie jederzeit einsehen:
divekit members list -d M0
$ divekit members list -d M0
Members for M0
source $DIVEKIT_MEMBERS/2026-07-16_10-24-55_M0_members.json
resolved /home/your-name/.divekit/members/2026-07-16_10-24-55_M0_members.json
b8520e99-2bad-c0de-b61c-1249a10f7a5a student-one
a70decaf-bad7-4c95-b211-d0bc95f48204 student-two
Die resolved-Zeile zeigt, wo die Mitglieder-Eingabe auf Ihrem Rechner tatsächlich liegt, und jede Zeile darunter ordnet eine Gruppen-UUID ihren Mitgliedern zu.
Die echte Distribution ausführen
Direkt vor diesem Schritt führen manche Teams gern noch eine zusätzliche lokale Vorschau aus:
divekit distribute -d M0 --provider local
Das kann nützlich sein, wenn Sie echte generierte Dateien wollen, bevor Sie GitLab anfassen.
Wenn M0 Ihre einzige Distribution ist, können Sie einfach ausführen:
divekit distribute
Wenn Sie explizit sein möchten, ist divekit distribute -d M0 genauso in Ordnung.
Das ist der Schritt, in dem Divekit das vorbereitete Origin-Repository in individualisierte Remote-Repositories verwandelt.
So sieht ein gesunder Lauf aus
$ divekit distribute -d M0
Configured members found. Choose action
● Keep Use 2 configured members
○ Add
○ Edit
○ Fresh
↑/↓ to navigate • enter to select • esc to cancel
┃ # Distribution Plan
┃
┃ https://gitlab.git.nrw/your-group
┃ └─ work
┃ ├─ M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a
┃ └─ M0-a70decaf-bad7-4c95-b211-d0bc95f48204
Proceed with distribution?
Yes No
Completed: 4/4
Distribution completed successfully!
Created repositories for 2 group(s)
Drei Dinge in diesem Ablauf sind lesenswert:
- der Configured members found-Prompt erscheint, weil bereits Mitglieder konfiguriert sind —
Keepverwendet sie unverändert; wären keine konfiguriert, würde sich hier stattdessen die Mitglieder-Eingabe öffnen - der Distribution Plan ist Ihr letzter Kontrollpunkt, bevor irgendetwas auf GitLab entsteht: Prüfen Sie Ziel-Gruppe und Repository-Namen, bevor Sie bestätigen
- die letzten Zeilen bestätigen, wie viele Gruppen ein Repository erhalten haben
Was während des Rollouts passiert
In einem typischen Lauf macht Divekit Folgendes:
- liest
.divekit/distributions/M0/config.json - erstellt die Ziel-Repositories
- individualisiert die Inhalte
- weist Mitglieder und Berechtigungen zu
- schreibt Zustandsdateien
.divekit/distributions/M0/individuals.json
.divekit/distributions/M0/remotes.json
So sieht Erfolg aus
Führen Sie aus:
divekit overview -d M0
Öffnen Sie dann die Ziel-GitLab-Gruppe und bestätigen Sie:
- Repositories existieren
- die Repository-Namen folgen dem Default-Muster
{{distribution}}-{{uuid}}, hier alsoM0-<uuid>— ein optionalername-Schlüssel inconfig.jsonkönnte diesen Default überschreiben - die erwarteten Mitglieder wurden zugewiesen
- die Inhalte unterscheiden sich dort, wo Sie Variation erwartet haben
Beispielhafte Form eines gesunden Overviews:
$ divekit overview -d M0
From cache (2026-07-16 10:31)
b8520e99-2bad-c0de-b61c-1249a10f7a5a [student-one]
└─ work https://gitlab.git.nrw/projects/1234
a70decaf-bad7-4c95-b211-d0bc95f48204 [student-two]
└─ work https://gitlab.git.nrw/projects/1235
Jeder Eintrag zeigt die UUID, die zugewiesenen Mitglieder in Klammern und das erstellte Repository als Link.
Die From cache (...)-Zeile bedeutet, dass die Mitgliederdaten aus der zwischengespeicherten Members-Datei stammen — mit --no-cache holen Sie sie frisch von GitLab.
Wenn die UUIDs oder Repository-Namen hier nicht Ihren Erwartungen entsprechen, halten Sie an und inspizieren Sie, bevor Sie erneut verteilen.
Schnelle Einordnung
| Was Sie sehen | Wie Sie es lesen | Was als Nächstes zu tun ist |
|---|---|---|
| erwartete UUIDs und Repository-Namen erscheinen in overview und GitLab | Normaler Erfolg beim ersten Rollout | Weiter zur Zustandsinspektion |
| Repositories existieren, aber die Namen sehen falsch aus | Config hat vermutlich funktioniert, die Benennung nicht | Namen folgen standardmäßig M0-<uuid>; prüfen Sie den Distributionsnamen und einen eventuellen name-Override in config.json |
| Repositories existieren, aber erwartete Mitglieder fehlen | Rollout teilweise erfolgreich, Mitgliedschaft nicht | Die konfigurierten Mitglieder mit divekit members list prüfen |
| remote wurde nichts erstellt | Rollout ist nicht wie erwartet durchgelaufen | Anhalten und inspizieren, bevor Sie es erneut versuchen |
Typische Fehler
individuals.json und remotes.json sind der echte Beleg dafür, was passiert ist.
Check
Nach der ersten echten Distribution:
divekit overview -d M0ausführen- die erstellten Repositories in GitLab verifizieren
divekit overview -d M0 mit der Ziel-GitLab-Gruppe: Dieselben UUIDs und Mitglieder erscheinen in beiden. Prüfen Sie in GitLab außerdem, dass die Repository-Namen dem erwarteten Muster M0-<uuid> folgen.