- Wann braucht man eine Migration?
- Was du beim Umzug beachten musst
- Neues Projekt am Zielserver anlegen
- GitLab
- GitHub
- Git Repository auf neuen Git Server übertragen
- 1. Prüfen, ob ein altes origin existiert
- 2. Remote URL auf das neue Projekt setzen
- 3. Alle lokalen Branches übertragen
- 4. Tags übertragen
- Tabelle: Unterschiede zwischen wichtigen Git Push Befehlen
- Migration GitLab vs GitHub
- Unterschiede zwischen GitHub und GitLab
- Übersicht der wichtigsten Unterschiede
- Welches System ist wofür besser geeignet?
- Unterschiede bei der Migration
- Empfehlungen und Best Practices
- FAQ
- Kann ich Issues, Merge Requests oder Wiki Inhalte übertragen?
- Was passiert, wenn im Zielprojekt bereits Dateien existieren?
- Was passiert mit alten Branches, die auf dem Server existierten, aber nicht lokal?
- Muss ich den Master Branch in Main umbenennen?
Wenn man ein bestehendes Git Repository auf einen neuen Git Server übertragen möchte, steht man oft vor der Frage, wie der Umzug technisch funktioniert und worauf man achten muss. Besonders dann, wenn der alte Server nicht mehr verfügbar ist oder man keinen Zugriff mehr hat. Genau das ist ein häufiges Szenario, zum Beispiel beim Wechsel von einem Self Hosted GitLab Server zu GitLab.com oder GitHub.
In diesem Beitrag zeige ich Schritt für Schritt, wie die Migration funktioniert, welche Git Befehle relevant sind und in welchen Fällen sich die Vorgehensweise unterscheidet. Außerdem erkläre ich typische Stolperfallen, Alternativen und gebe Antworten auf häufige Fragen.
Wann braucht man eine Migration?
Typische Szenarien:
- Der alte Git Server ist nicht mehr erreichbar.
- Du hast nur noch ein lokales Repository auf deinem PC oder Server.
- Der alte Server gehört nicht mehr dir, z. B. Firmenwechsel.
- Ein Projekt soll zentral zu GitLab.com oder GitHub umziehen.
- Du möchtest mehrere Repositories konsolidieren.
In diesen Fällen ist es wichtig zu wissen, ob du alle alten Daten noch hast oder nur eine lokale Kopie des Standes der letzten Klonung.
Was du beim Umzug beachten musst
Bevor du ein Git Repository migrierst, solltest du diese Punkte prüfen:
- Hast du noch Zugriff auf den alten Server?
Wenn ja, kannst dugit push --mirrorverwenden und wirklich alles übernehmen. - Hast du nur noch eine lokale Kopie?
Dann kannst du nur die Branches und Tags übertragen, die lokal vorhanden sind. - Wurden Merge Requests, Issues, Wikis oder Pipelines genutzt?
Diese Daten sind nicht Teil des Repositories und können nicht per Git übertragen werden. - GitLab und GitHub übertragen nur Git Daten über git push, keine Server-Metadaten.
Neues Projekt am Zielserver anlegen
Unabhängig davon, ob du GitLab oder GitHub nutzt, musst du zuerst ein neues leeres Projekt erstellen.
GitLab
- Gruppe öffnen
- „New project“
- „Create blank project“
- Option „Initialize repository with a README“ deaktivieren, wenn du migrieren möchtest
(sonst entsteht Merge Konflikt beim Push)
GitHub
- Repositories
- „New“
- „Repository name“ wählen
- Keine README, keine .gitignore erstellen
- Repository erstellen
Git Repository auf neuen Git Server übertragen
1. Prüfen, ob ein altes origin existiert
git remote -v
2. Remote URL auf das neue Projekt setzen
git remote set-url origin <NEUE-URL>
Beispiel GitLab:
https://gitlab.com/benutzer/projekt.git
Beispiel GitHub:
https://github.com/benutzer/projekt.git
3. Alle lokalen Branches übertragen
Wenn der alte Server nicht mehr erreichbar ist:
git push -u origin --all #alternativ kann auch git push --mirror origin verwendet werden
Dieser Befehl überträgt:
- alle lokalen Branches
- inkl. Master oder Main
- setzt Tracking für zukünftige Pushs
4. Tags übertragen
Wenn das Projekt Tags verwendet hat:
git push origin --tags
Tabelle: Unterschiede zwischen wichtigen Git Push Befehlen
| Befehl | Funktion | Empfehlung |
|---|---|---|
git push --mirror origin | Kopiert alle Branches, Tags, Remote Einstellungen und Referenzen | Nur verwenden, wenn der alte Server noch erreichbar ist |
git push -u origin --all | Überträgt alle lokalen Branches | Standard für Migration ohne alten Server |
git push origin --tags | Überträgt alle Tags | Nach dem Push der Branches ausführen |
git push -f origin | Erzwingt das Überschreiben des Ziel-Branches | Nur bei Konflikten mit leerem Zielrepo |
git remote set-url origin <URL> | Ändert die Remote Adresse | Wichtigster Schritt bei der Migration |
Migration GitLab vs GitHub
| Thema | GitLab | GitHub |
|---|---|---|
| Projekt ohne README starten | Möglich | Möglich |
| Import Funktionen (Web UI) | Sehr umfangreich | Umfangreich, aber weniger als GitLab |
| Übernahme von Issues | Nein (nur über API oder Exporte) | Nein |
| Push Befehle identisch | Ja | Ja |
| LFS Migration | Unterstützt | Unterstützt |
In der Praxis gibt es keine großen Unterschiede, da beide Plattformen Git nativ unterstützen. Die Migration erfolgt bei beiden über dieselben Befehle.
Unterschiede zwischen GitHub und GitLab
Auch wenn GitHub und GitLab auf den ersten Blick sehr ähnlich wirken und beide hervorragend als Git Server fungieren, gibt es einige Unterschiede, die beim Umziehen eines Git Repositories oder beim langfristigen Arbeiten relevant sein können. Viele Einsteiger fragen sich, ob der Umzug auf GitHub anders funktioniert als auf GitLab oder ob bestimmte Funktionen fehlen. Die gute Nachricht: Die Git Befehle sind bei beiden identisch, aber die Plattformen selbst unterscheiden sich in einigen Bereichen deutlich.
Übersicht der wichtigsten Unterschiede
| Bereich | GitHub | GitLab |
|---|---|---|
| Fokus | Größte Entwicklerplattform weltweit, starker Community Fokus | DevOps Plattform mit integriertem CI/CD und Projektmanagement |
| Private Repositories | Kostenlos, aber mit begrenzten Features | Kostenlos und umfangreiche Funktionen, auch für Teams |
| CI/CD | GitHub Actions, sehr flexibel | GitLab CI/CD nativ integriert und eng verzahnt |
| Projektstruktur | Flache Struktur, Fokus auf Repositories | Starke Gruppen- und Untergruppenstruktur |
| Issue Management | Einfach, übersichtlich | Umfangreicher mit Boards, Epics, Roadmaps |
| Wikis | Pro Repository | Pro Projekt mit mehr Verwaltungsfunktionen |
| Import Tools | Gut, aber nicht so umfangreich wie GitLab | Sehr umfangreiche Importfunktionen für GitHub, Bitbucket, Jira usw. |
| Self Hosting | GitHub Enterprise, teuer | GitLab kann komplett selbst gehostet werden, Community Edition kostenlos |
| Rechteverwaltung | Einfach gehalten | Sehr granular und rollenbasiert |
| Kostenloser Storage | Für LFS limitiert | Höherer freier Speicher für Repos und Container Registry |
Welches System ist wofür besser geeignet?
GitHub ist ideal, wenn:
- du ein Open Source Projekt startest
- du viele externe Entwickler einbeziehen möchtest
- du auf eine große Community und viele fertige Integrationen setzt
- du GitHub Actions verwenden möchtest
GitLab ist ideal, wenn:
- du eine Komplettlösung für DevOps suchst
- du viele Projekte in Gruppen strukturieren möchtest
- du Self Hosting oder vollständige Kontrolle brauchst
- du CI/CD ohne zusätzliche Tools nutzen möchtest
Unterschiede bei der Migration
Für die eigentliche Migration eines Git Repositories spielt es kaum eine Rolle, ob du GitHub oder GitLab verwendest, da beide dieselben Git Standards unterstützen. Die Unterschiede liegen eher im Umfeld:
- GitHub legt automatisch den Branch main an, GitLab macht das nur optional.
- GitLab zeigt nach dem Push automatisch Hinweise zur Erstellung von Merge Requests an.
- GitHub legt mehr Wert auf Pull Requests statt Merge Requests.
- GitLab unterstützt Mirror Repositories nativ, GitHub nur über Automation oder Actions.
- GitLab bietet umfangreiche Importassistenten, um GitHub Projekte inklusive Issues zu übernehmen.
Empfehlungen und Best Practices
- Projekt öffentlich oder privat? Vorher im Zielprojekt festlegen.
- SSH Key oder HTTPS? SSH spart das ständige Eingeben von Passwörtern.
- Lokale Branches prüfen, bevor du sie hochlädst.
- Alte Branches, die nicht mehr gebraucht werden, vorher löschen.
- Nach dem Push prüfen, ob alle Branches und Tags korrekt übernommen wurden.
FAQ
Kann ich Issues, Merge Requests oder Wiki Inhalte übertragen?
Nein, diese Daten liegen nicht im Git Repository, sondern auf dem Server. Eine Migration ist nur über Exporte oder APIs möglich.
Was passiert, wenn im Zielprojekt bereits Dateien existieren?
Dann kommt es zu Konflikten. Erstelle das Zielprojekt am besten komplett leer.
Was passiert mit alten Branches, die auf dem Server existierten, aber nicht lokal?
Sie sind verloren, wenn du keinen Zugriff mehr auf den alten Server hast.
Muss ich den Master Branch in Main umbenennen?
Nein. GitLab und GitHub akzeptieren beide Namen.
