EMZETT.Git Mirror Clone
Kurz: Eine vollständige Kopie eines Git-Repositories inkl. aller Branches, Tags und der kompletten Commit-History — nicht nur ein normaler Checkout zum Arbeiten.
Genauer: git clone --mirror <url> erzeugt ein “bare” Repository (kein Arbeitsverzeichnis, nur der .git-Ordner). Danach lässt sich mit git push --mirror <neue-url> die komplette History 1:1 in ein neues Ziel-Repo übertragen. Zum eigentlichen Weiterarbeiten braucht man danach trotzdem einen normalen git clone vom neuen Repo — der Mirror-Ordner ist nur ein Zwischenschritt.
Kontext bei uns: So wurde das Bellator-Repo komplett (inkl. History) vom alten Partner-Account auf den eigenen GitHub-Account umgezogen, bevor daraus “Emzett” wurde.
Im Detail
Vollständiger Ablauf
Der vollständige Ablauf eines Repo-Umzugs mit Mirror-Clone besteht aus drei Schritten:
# 1. Vollständige Kopie inkl. aller Refs erzeugen (bare Repository)
git clone --mirror https://github.com/alter-account/bellator.git
# 2. In das neue, leere Ziel-Repo pushen (alle Branches, Tags, History)
cd bellator.git
git push --mirror https://github.com/eigener-account/emzett.git
# 3. Für die eigentliche Weiterarbeit: normaler Clone vom neuen Repo
git clone https://github.com/eigener-account/emzett.gitWas “bare Repository” konkret bedeutet
Ein normales, geklontes Repository hat zwei Teile: den .git-Ordner (alle History/Metadaten) und ein Arbeitsverzeichnis (die tatsächlich ausgecheckten Dateien, die man bearbeitet). Ein “bare” Repository, wie es --mirror erzeugt, besteht NUR aus dem .git-Inhalt, ohne Arbeitsverzeichnis — es gibt also gar keine auscheckbaren Dateien, mit denen man direkt arbeiten könnte. Das ist beabsichtigt: Ein bare Repository ist reiner Datencontainer, gedacht als Zwischenstation oder Ziel für Pushes, nicht zum direkten Bearbeiten. Das erklärt auch, warum nach dem Mirror-Push trotzdem noch ein normaler git clone vom neuen Repo nötig ist.
Unterschied zu normalem Clone + Push
Der entscheidende Unterschied zu einem normalen git clone + git push: Ein normaler Clone holt zwar auch die volle History des aktuell ausgecheckten Branches, aber NICHT automatisch alle anderen Branches/Tags, und ein normaler push überträgt nur den aktuellen Branch, nicht das gesamte Referenz-Geflecht. Bei einem Repo-Umzug (anders als beim täglichen Arbeiten) will man aber wirklich 1:1 alles mitnehmen, inklusive Branches, die man selbst vielleicht nie ausgecheckt hatte — etwa alte Feature-Branches oder Tags von vergangenen Releases, die für die vollständige Historie relevant bleiben.
Was NICHT mitkommt
Ein wichtiger Punkt, der bei Repo-Umzügen leicht übersehen wird: Ein Mirror-Clone überträgt zwar die komplette Git-History, aber NICHT plattformspezifische Metadaten wie GitHub Issues, Pull Requests, Wiki-Seiten, Releases (als GitHub-Objekte, nicht als Git-Tags) oder Repository-Einstellungen (Branch-Protection-Regeln, Webhooks, konfigurierte Secrets). Diese Dinge leben außerhalb des reinen Git-Objektmodells in GitHubs eigener Datenbank und müssen bei einem echten Plattform-Umzug separat migriert oder neu eingerichtet werden.
Authentifizierung beim Mirror-Push
Da ein Mirror-Push potenziell sehr viele Refs auf einmal überträgt, ist er besonders anfällig für Authentifizierungsprobleme bei großen Repositories — ein abgelaufenes Token oder eine falsch konfigurierte SSH-Verbindung führt oft erst mitten im Transfer zu einem Fehler, wodurch das Ziel-Repo einen unvollständigen Zwischenzustand haben kann. Es empfiehlt sich deshalb, nach einem Mirror-Push die Anzahl der Branches/Tags im Ziel-Repo mit dem Original zu vergleichen, bevor das alte Repository gelöscht oder archiviert wird.
Siehe auch: SSH-Key (Git-Authentifizierung), Git