Dein Blog zum Thema digitales Business

Ein Repository von einer Organisation in eine andere zu verschieben, dauert in GitHub wenige Klicks. Was danach funktioniert und was zuerst stillschweigend ausfällt, hängt davon ab, welche Konfiguration am Repository hängt und welche an der Organisation. Diese Unterscheidung wird in der Praxis regelmäßig verwechselt. Dieser Artikel sortiert, was tatsächlich mitzieht und wo du nach einem Transfer manuell nacharbeiten musst.

Was ein Transfer technisch bedeutet

Bei einem GitHub-Repository-Transfer wechselt das Repository den Besitzer: von einem Nutzerkonto in eine Organisation, oder von einer Organisation in eine andere. Issues, Pull Requests, Wiki, Stars, Watcher und die Git-Historie inklusive Commits gehen laut GitHub-Dokumentation mit über. Git-LFS-Objekte werden im Hintergrund automatisch mitverschoben, bei großen Datenmengen kann das dauern. Alte URLs leiten auf den neuen Pfad weiter, solange am alten Pfad kein neues Repository oder Fork angelegt wird: Das würde die Weiterleitung dauerhaft löschen.

Was automatisch mitzieht: Webhooks, Actions-Secrets, Deploy Keys

Der verbreitetste Irrtum bei Repository-Transfers lautet, Webhooks, GitHub-Actions-Secrets und Deploy Keys würden beim Transfer verloren gehen und müssten komplett neu angelegt werden. Laut GitHub-Dokumentation ist das falsch. Die Dokumentation zum Transfer hält fest: Enthält das transferierte Repository Webhooks, Services, Secrets oder Deploy Keys, bleiben diese nach dem Transfer mit dem Repository verbunden. Das gilt unabhängig davon, ob der Transfer zwischen zwei Organisationen oder von einem Nutzerkonto in eine Organisation stattfindet.

Für den Betrieb heißt das: CI/CD-Pipelines, die auf Repository-Secrets zugreifen, laufen nach dem Transfer ohne Neukonfiguration der Secrets weiter. Eingehende Webhooks an externe Systeme (Monitoring, Ticketsysteme, Deploy-Trigger) bleiben aktiv. Deploy Keys für Git-Zugriff auf das Repository funktionieren unverändert.

Was nicht automatisch mitzieht: GitHub-App-Installationszugriff

GitHub-Apps werden nicht pro Repository, sondern pro Account oder Organisation installiert. Laut GitHub-Dokumentation muss dieselbe App auf jedem Account, der sie nutzen soll, einzeln installiert werden. Eine Installation ist an die Organisation gebunden, in der sie vorgenommen wurde.

Wandert ein Repository in eine neue Organisation, in der die App bisher nicht installiert ist, hat die App dort keinen Zugriff, auch wenn sie in der alten Organisation auf genau dieses Repository zugreifen konnte. Daraus folgt: Die App muss in der Zielorganisation neu installiert und für das Repository autorisiert werden, bevor automatisierte Abläufe (Code-Scans, Status-Checks, Bot-Kommentare) wieder greifen.

Details zur granularen Rechtevergabe von GitHub-Apps findest du im Beitrag GitHub Apps statt Personal Access Tokens: Installationsrechte granular begrenzen.

Was nicht automatisch mitzieht: Runner-Group-Zuordnung

Self-hosted Runner Groups sind laut GitHub-Dokumentation Ressourcen der Organisation (bzw. des Enterprise), nicht des einzelnen Repositorys. Beim Anlegen einer Runner Group legst du eine Zugriffs-Policy fest, die bestimmt, welche Repositorys innerhalb dieser Organisation die Gruppe nutzen dürfen, entweder eine definierte Liste oder alle Repositorys der Organisation.

Diese Policy existiert ausschließlich innerhalb der Organisation, in der die Runner Group angelegt wurde. Daraus folgt: Nach einem Transfer in eine andere Organisation taucht das Repository in keiner Runner-Group-Policy der Zielorganisation auf und muss dort explizit einer Gruppe zugeordnet werden, sonst bleiben Workflows, die auf self-hosted-Runner verweisen, ohne verfügbaren Runner stehen.

Details zum Scoping von Runner Groups als geteilte Angriffsfläche findest du im Beitrag Self-hosted Runner als geteilte Angriffsfläche.

Was nicht automatisch mitzieht: Environment-Reviewer-Teams

Deployment-Environments können Required Reviewers definieren: Personen oder Teams, die einen Workflow-Job freigeben müssen, bevor er in die Umgebung deployt. Laut GitHub-Dokumentation lassen sich bis zu sechs Personen oder Teams als Required Reviewer eintragen.

Ein Team ist laut GitHub-Dokumentation an seine Organisation gebunden: Mitglieder eines Teams sind ausschließlich Mitglieder derselben Organisation. Ein Team-Verweis aus der alten Organisation existiert in der Zielorganisation schlicht nicht. Daraus folgt: Nach dem Transfer muss die Required-Reviewer-Konfiguration jeder betroffenen Environment in der Zielorganisation neu gesetzt werden, sonst blockiert ein Deployment entweder komplett oder die Freigabe läuft unbemerkt ins Leere.

Ein vereinfachtes Beispiel, wie ein solcher Verweis in der Konfiguration aussieht und warum er nach dem Transfer ins Leere zeigt:

Environment: production
Required reviewers:
  - team: alte-org/platform-leads   # existiert nur in der Quell-Organisation
  - user: jdoe                      # Personen-Zuordnung bleibt gültig

Checkliste für den Transfer-Tag

Wer diese Liste vor dem Transfer einmal durchgeht, vermeidet den typischen Ablauf: Transfer ist durch, der erste Deployment-Workflow bleibt stehen, und die Fehlersuche beginnt bei den Secrets, obwohl die nie das Problem waren.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.