Von GitHub zu Codeberg migrieren – eine Methode für Faule

• Beim Umzug einiger Projekte von GitHub zu Codeberg wird zusammengefasst, wie man mit minimalem Aufwand eine Migration beginnen kann
• Über die Repository-Importfunktion von Codeberg ist eine vollständige Migration inklusive Issues, PRs und Releases möglich, und UI und Workflow ähneln GitHub
• Statisches Page-Hosting kann durch codeberg.page ersetzt werden, außerdem gibt es Alternativen wie grebedoc.dev oder statichost.eu
• Die größte Schwierigkeit ist der Aufbau der CI-Umgebung: Auf die macOS-Runner von GitHub und das kostenlose Ausführungsvolumen muss verzichtet werden, Ersatz ist mit Forgejo Actions oder Woodpecker CI möglich
• Nach der Migration kann das GitHub-Repository als schreibgeschütztes Archiv erhalten oder gespiegelt werden, sodass die Verbindung zum Open-Source-Ökosystem nicht vollständig abbricht

---

Der Migrationsprozess von GitHub zu Codeberg

• Auf Basis der Erfahrung, einige Repositories von GitHub zu Codeberg zu migrieren, werden der tatsächliche Schwierigkeitsgrad und die Benutzerfreundlichkeit des Migrationsprozesses erläutert
  • Die Migration wurde lange aufgeschoben, weil Codeberg als noch nicht ausreichend vorbereitet erschien, doch je nach Projekt kann der Umzug überraschend einfach sein
  • Das Ziel ist nicht eine perfekte Konfiguration, sondern den einfachsten Weg zu finden, eine Migration zu starten

• Repository- und Issue-Migration

  • Codeberg bietet eine Importfunktion für GitHub-Repositories, mit der sich Issues, PRs, Releases und deren Artefakte gemeinsam migrieren lassen
    • Dabei bleiben Issue-Nummern, Labels und Autorinformationen erhalten
    • Die UI von Codeberg ist fast identisch mit GitHub und bietet im Vergleich zu den komplexen Verfahren, die beim Wechsel anderer Issue-Tracker zu GitHub nötig sind, eine deutlich einfachere Erfahrung

• Hosting statischer Seiten

  • Wer bisher GitHub Pages verwendet hat, kann stattdessen codeberg.page nutzen
    • Es gibt zwar keine offizielle Verfügbarkeitsgarantie (SLO), in der Praxis wurde jedoch kein Ausfall erlebt
    • Die Funktionsweise ist ähnlich wie bei GitHub Pages: HTML wird in einen Branch gepusht
    • Als Alternativen können auch grebedoc.dev oder statichost.eu verwendet werden

• Schwierigkeiten bei der CI-Umgebung

  • Der kniffligste Teil der Migration ist der Aufbau der CI-Umgebung
    • GitHub bietet kostenlose macOS-Runner und unbegrenztes Ausführungsvolumen für öffentliche Repositories, darauf muss man bei Codeberg verzichten
    • Als Lösung lassen sich sprachspezifische Cross-Compilation und Self-Hosting von Forgejo-Actions-Runnern nutzen

  • Forgejo Actions vs. Woodpecker CI

    • Bei Codeberg gilt Woodpecker CI als stabiler, aber Forgejo Actions bietet GitHub-Actions-Nutzern eine vertrautere Umgebung
    • UI und YAML-Syntax sind nahezu identisch, und die meisten bestehenden GitHub-Actions-Workflows funktionieren unverändert
    • Wenn in GitHub Actions etwa uses: dtolnay/rust-toolchain verwendet wurde, genügt es in Forgejo Actions, dies zu uses: https://github.com/dtolnay/rust-toolchain zu ändern
    • Die aktuelle Dokumentation zu Forgejo Actions auf Codeberg ist nicht auf dem neuesten Stand, dazu existiert ein entsprechender PR

  • Wenn ein macOS-Runner nötig ist

    • Wenn ein macOS-Build zwingend erforderlich ist, kann man GitHub Actions weiter nutzen und Commits vom Codeberg-Repository nach GitHub spiegeln
    • Forgejo Actions lässt sich so konfigurieren, dass es die GitHub-API pollt und den CI-Status nach Codeberg synchronisiert
    • Andere CI-Dienste mit macOS-Builds wurden ebenfalls ausprobiert, ihre Integration mit Codeberg ist jedoch nicht so unkompliziert wie bei GitHub Actions

• Umgang mit dem GitHub-Repository

  • Nach der Migration wird das GitHub-Repository durch eine angepasste README archiviert
    • Es ist auch möglich, Pushes von Codeberg nach GitHub einzurichten, dann können Nutzer jedoch weiterhin PRs erstellen und Kommentare zu Issues hinterlassen
    • Manche deaktivieren im GitHub-Repository die Issue-Funktion, doch dann verschwinden alle Issues als 404 und PRs lassen sich nicht deaktivieren
    • Als Beispiel nutzt das Repository libvirt/libvirt eine GitHub Action, die alle PRs automatisch schließt
  • Dieser Ansatz kann sich negativ auf Self-Hosting und das Open-Source-Ökosystem insgesamt auswirken
    • Nutzer verlieren möglicherweise den Anreiz, Build-Optimierungen oder die Häufigkeit von Release-Datei-Downloads zu verbessern
    • Während der Übergangsphase kann man auch einen schreibgeschützten Mirror beibehalten oder GitHub Pages und Actions parallel weiterverwenden

[GN⁺]

Hacker-News-Kommentare

• Ich habe nichts gegen Codeberg an sich, aber es ist kein vollständiger Ersatz für GitHub
  Für persönliche Code-Repositories oder experimentelle Skripte gibt es viele Einschränkungen, und private Repositories sind auf 100 MB begrenzt
  Außerdem kann man dort keine Homepage wie mit GitHub Pages hosten. Für solche Zwecke ist es realistischer, Forgejo selbst zu hosten
  Das ist auch im Codeberg-FAQ gut erklärt

  • Man kann auch mit Codeberg Pages eine Homepage auf Codeberg hosten
  • Ich hoste meine Website ebenfalls auf Codeberg Pages. Die obige Information ist falsch → Codeberg-Pages-Dokumentation
  • Ich finde die Aussage schwer nachvollziehbar, dass „einen eigenen Git-Server zu betreiben zu aufwendig ist“. Wenn man einfach nur einen Ort zum Pushen von Code will, reicht ein einzelner SSH-Server völlig aus
  • Das Projekt Code Storage von Pierre ist interessant, weil es als API-basierter Git-Server den Betriebsaufwand reduziert
  • (Kleine Eigenwerbung) Ich entwickle gerade Monohub, eine GitHub-Alternative. Private Repositories sind standardmäßig dabei, und PRs werden ebenfalls unterstützt. Beispiel für ein öffentliches Repository

• Der Grund, warum ich OSS-Projekte auf GitHub veröffentliche, ist simpel — weil dort die Community ist
  Wenn ich nur Code hochladen wollte, würde ich ihn direkt per SSH oder SFTP hosten

  • Dass die Community nur auf GitHub bleibt, ist ein klassisches Henne-oder-Ei-Problem. Irgendjemand muss zuerst auf eine andere Plattform umziehen, damit sich das Ökosystem verlagert
    Ich veröffentliche nur auf meiner persönlichen Gitea-Instanz und kümmere mich nicht um Stars oder Vermarktung
  • Wer auf GitHub bleibt, ist nur noch eine FOSS-Community, die geschlossene Abhängigkeiten akzeptiert. Eher sorgen die Richtlinien von GitHub dafür, dass Leute gehen
  • Bei manchen Projekten kann man ohne GitHub-Account gar nicht erst mitmachen. Zum Beispiel ist dieses crates.io-Issue seit 10 Jahren ungelöst, und Reservoir von Lean verlangt mindestens 2 GitHub-Stars. Das wirkt wie eine stärkere Abhängigkeit von Microsoft
  • GitHub stellt kostenlos viele CI-Ressourcen bereit. Vor allem für macOS-Runner gibt es kaum Alternativen. Dadurch kann man in vielen verschiedenen Umgebungen testen
  • Ich habe auch angefangen, Git-Hosting auf meinem Homeserver zu betreiben, um von GitHub wegzukommen, aber das Dopamin beim Pushen von Commits wie früher ist verschwunden. Es fühlt sich an, als hätte Open Source durch die Kommerzialisierung an Reiz verloren

• Ich verwalte alle meine privaten Projekte mit selbstgehostetem Forgejo. Ich vermisse GitHub überhaupt nicht
  Mit Tailscale kann ich den Zugriff einschränken und dadurch AI-Crawler blockieren

  • Ich betreibe Forgejo ebenfalls seit einigen Jahren selbst. Ich habe sogar ein Installations-Tutorial geschrieben und bin kürzlich bei Hetzner auf zwei Raspberry Pis umgezogen. Es ist schneller und stabiler als GitHub
  • Früher habe ich GitLab benutzt, aber Forgejo ist als leichtgewichtiges einzelnes Go-Binary viel ressourcenschonender. Es lässt sich einfach mit Docker betreiben, und es macht auch Spaß, Funktionen selbst zu hacken
  • Ich habe Forgejo installiert, als bei GitHub das Erstellen von Agent-Accounts blockiert wurde, und innerhalb von 15 Minuten selbst die Funktion zum Ausblenden von „Viewed“-Dateien in PR-Reviews hinzugefügt
  • In letzter Zeit sind mehrere große OSS-Projekte zu Forgejo gewechselt, und ich bin mitgegangen — bisher bin ich sehr zufrieden
  • Ich habe auch den Forgejo-Runner per Docker installiert und lasse CI darüber laufen. Es gibt ein eigenes Registry-Feature, sodass ich meine App als Docker-Image verteile

• In Zukunft wird es wohl immer wichtiger, GitHub-Alternativen zu bewerten
  Aber GitHub hat CI und Multi-Arch-Builds zum Standard gemacht, sodass es für communitygetriebene Alternativen schwer ist, zu konkurrieren

  • CI muss nicht zwangsläufig an GitHub gebunden sein. Tatsächlich sind die meisten CI-Systeme nur einfache Befehlsausführer. Für kleine Teams kann man oft auch ganz ohne CI arbeiten
  • Ich verstehe nicht, warum es unvernünftig sein soll, CI selbst zu betreiben. Repository und CI zu trennen ist überhaupt kein Problem
  • Für mich ist wichtiger als CI die PR- und Code-Review-Erfahrung. GitHub hat da immer noch viele unbequeme Stellen, und das Issue-System ist auf dem Stand von vor 20 Jahren
  • Solche zentralisierten Schichten entstehen letztlich aus einem Kontrollbedürfnis. Mit einem lokal orientierten, verteilten Workflow kann man genauso gut und angenehm entwickeln

• GitHub bietet vieles „kostenlos“ an, aber der Preis dafür ist wahrscheinlich, dass es für Datensammlung und Training verwendet wird
  Codeberg unterstützt keine privaten Repositories, daher kann man auch nicht verhindern, dass Copilot öffentliche Repositories abgreift
  Laut dem Codeberg-FAQ wird bei Bedarf an privaten Projekten selbstgehostetes Forgejo empfohlen

  • Aber mein Codeberg-Repository ist privat eingestellt. Ganz unmöglich scheint es also nicht zu sein

• Unser Unternehmen ist vollständig von GitHub auf selbstgehostetes GitLab umgezogen
  Es läuft hinter Tailscale, daher gibt es keinen SSO-Aufwand, und die CI-Runner laufen auf EKS und einem GPU-Cluster. Ich kann Leuten helfen, die über einen ähnlichen Umzug nachdenken

  • Mich würde interessieren, ob ihr auch Forgejo in Betracht gezogen habt. GitLab ist stark bei CI/CD auf Enterprise-Niveau, aber für kleinere Projekte scheint Forgejo die leichtere Wahl zu sein
  • Mich würde auch interessieren, ob selbstgehostetes GitLab Funktionen wie automatisierte Benutzerbereitstellung (SCIM) unterstützt

• Einfach nur zu sagen „Lasst uns GitHub ersetzen“ hat wenig Bedeutung. Es braucht neue Gewohnheiten und ein neues Wertversprechen
  So wie GitHub einst SourceForge ersetzt hat, muss die nächste Plattformgeneration Code-Schreiben und Zusammenarbeit in Echtzeit verbinden
  Zum Beispiel könnte es eine Struktur werden, bei der wie in Google Docs für jeden Prompt ein Commit erzeugt wird

  • Allerdings spielen auch geopolitische Gründe eine große Rolle. In Europa und anderswo gibt es starke Bewegungen, die Abhängigkeit von US-Technologie zu vermeiden
  • Durch die jüngsten Copilot-Kontroversen ist Vertrauen verloren gegangen, und es entsteht ein Trend, GitHub zu verlassen
  • Für mich ist nicht einfach die Funktionalität wichtig, sondern die Verfügbarkeit (Uptime). GitHub liegt heutzutage nicht einmal mehr bei 99 %

• Codeberg ist idealistisch, aber in der Realität gibt es erhebliche Stabilitätsprobleme
  Da es ohne Cloudflare betrieben wird, ist es anfällig für DDoS-Angriffe, und es kommt oft zu Ausfällen. Wenn man während der Entwicklung nicht auf das Remote-Repository zugreifen kann, ist das wirklich frustrierend

  • Ich nutze GitHub oder Codeberg nur für asynchrones Teilen von Code. Selbst wenn das Remote ausfällt, sollte man lokal weiterarbeiten können
  • Ich mag Cloudflare nicht, aber in der Praxis ist es für die Abwehr von Bot-Traffic und Angriffen praktisch unverzichtbar. Alternative Dienste wurden bei mir sogar noch häufiger blockiert oder waren instabil. Da merkt man den harten Widerspruch zwischen Prinzipien und Realität
  • Wenn man sich das Uptime-Monitoring von GitHub ansieht, lag es in den letzten 90 Tagen nur bei rund 90 %. Codeberg ist im Gegenteil stabiler
  • Auch mein persönlicher Git-Server wurde durch wahlloses Scraping von AI-Crawlern langsamer. Am Ende habe ich die IPs großer Unternehmen einfach alle blockiert
  • Der Kern von Git ist Dezentralität. Selbst wenn das Remote ausfällt, sollte die neueste Version lokal vorhanden sein

• Seit der Übernahme durch Microsoft nutze ich GitHub fast gar nicht mehr. Der einfache, E-Mail-basierte Workflow von Sourcehut gefällt mir sogar besser
  Auch bei CI denke ich, dass ein kommando-basierter Ansatz, der lokal ausführbar ist, völlig ausreicht

• Code-Repositories sollten ihrem Wesen nach dezentral und föderiert sein
  Dank des kryptografischen Signatursystems von Git (GPG/SSH) kann man das Vertrauen in das Repository und das Vertrauen in Commits voneinander trennen
  Zentral braucht man dann nur einen Key-Server und die Namespace-Verwaltung, der Rest kann verteilt werden

  • Radicle ist genau ein Projekt, das solches dezentrales Git-Hosting anstrebt
  • Die meisten Entwickler können ihre Signaturschlüssel allerdings nicht ordentlich verwalten
  • Aus diesem Grund werden föderierte Protokolle wie Tangled oder ForgeFed in Forgejo integriert
  • Auch git-bug ist ein interessanter Ansatz. Ich habe es noch nicht ausprobiert, aber es scheint Potenzial zu haben