GitHub Developer Exodus 2026: Solltest du wirklich gehen?
Ich war gerade dabei, einen Pull-Request zu überprüfen, als die X-Benachrichtigung einging. Mitchell Hashimoto – der Typ, der Vagrant, Terraform und Ghostty entwickelt hat – zog sein 50.000-Sterne-Terminalprojekt von GitHub. Er war seit Februar 2008 GitHub-Benutzer 1299. Er hatte die Website nach eigenen Angaben über achtzehn Jahre lang praktisch jeden Tag geöffnet.
Ich habe seinen Beitrag zweimal gelesen. Dann schloss ich den PR, den ich überprüfte, öffnete einen neuen Tab und begann, „GitHub alternatives 2026“ in eine Suchleiste einzugeben, von der ich nie gedacht hätte, dass ich diesen Ausdruck jemals eingeben würde.
Die Sache ist die, ich bin nicht Mitchell Hashimoto. Ich habe kein 50.000-Sterne-Projekt. Ich habe keinen Einfluss darauf, dass mehrere „kommerzielle und FOSS-Anbieter“ bereit sind, mich zu hosten. Ich bin ein arbeitender Ingenieur mit etwa vierzig aktiven repos bei mejba.me, Ramlit Limited und einer Handvoll Kundenprojekten. Die Berechnung, ob ich GitHub verlassen sollte, ist nicht dieselbe wie seine.
Aber die Frage wurde diese Woche so laut, dass ich sie nicht ignorieren konnte. Also verbrachte ich vier Tage damit, die Zahlen durchzugehen – tatsächlich testete ich GitLab, Codeberg und Nicht weil einer von ihnen offensichtlich besser ist. Das sind sie nicht. Die Überraschung ist, was der Vergleich darüber verrät, was GitHub im Jahr 2026 tatsächlich geworden ist und welche Art von Entwicklern sich jetzt bewegen sollten und welche Art von Entwicklern unbedingt dabei bleiben und sich einfach anpassen sollten.
Ich wünschte, jemand hätte diesen Beitrag geschrieben, bevor ich einen Sonntag dafür verloren habe.
Die Woche, die die Annahme „GitHub ist für immer“ zunichte machte
Sie kennen die Schlagzeilen bereits. Lassen Sie mich den Zeitplan eng festlegen, da die Reihenfolge wichtiger ist als die einzelnen Vorfälle.
23. April 2026. Zwischen 16:05 UTC und 20:43 UTC führte eine Regression in der Zusammenführungswarteschlange von Laut GitHubs eigenem Vorfall report waren 2.092 Pull-Anfragen in 230 repositories betroffen. Der Fehler war kein Verfügbarkeitsfehler – Git-Vorgänge funktionierten weiterhin, der API gab weiterhin Daten zurück, die Statusseite blieb größtenteils grün. Der Fehler bestand darin, dass die Commit-Korrektheit fehlerhaft war. Code, von dem die Teams dachten, er hätte ihn zusammengeführt, wurde durch nachfolgende Zusammenführungen in derselben Warteschlange rückgängig gemacht. Es dauerte drei Stunden und dreiunddreißig Minuten, bis
Lesen Sie diesen Absatz bei Bedarf noch einmal. Eine Versionskontrollplattform stoppte kurzzeitig die zuverlässige Verfolgung von Versionen.
27. April 2026. Der Elasticsearch-Cluster von GitHub – das Subsystem, das PR-Listenansichten, Problemsuche, Projektboard-Filter und den Großteil der Benutzeroberfläche, auf die Sie tatsächlich klicken, unterstützt – war überlastet. Der CTO von Stundenlang waren die zugrunde liegenden Daten in Ordnung, aber die Schnittstelle, die die Daten findet hat die Entwickler angelogen. Leute beschuldigten Teamkollegen, Arbeiten zu löschen, die nicht gelöscht worden waren. Die Teams führten Besprechungen in der Annahme durch, dass PRs, die sie nicht sehen konnten, nicht mehr existierten.
28. April 2026. Drei Dinge passierten im selben Nachrichtenzyklus. GitHub veröffentlichte eine öffentliche Entschuldigung für die Zuverlässigkeit, in der das Unternehmen eine „Verfügbarkeit zuerst“-Haltung einführte. Wiz Research hat CVE-2026-3854 veröffentlicht – einen CVSS 8.7 kritischen RCE, der es jedem authentifizierten Benutzer ermöglicht, mit einem einzigen git push Remote-Codeausführung auf dem Backend von Und Mitchell Hashimoto veröffentlichte „Ghostty verlässt GitHub.“
Drei Ausfälle, drei verschiedene Schichten des Stapels, eine Woche. Das sind die Daten.
Aber hier ist der Teil, der nicht auf die Titelseite von Hacker News passte: **Die von Drittanbietern überwachte Betriebszeit von AWS S3 läuft im Kontext mit einem Designziel von „elf Neunen“ – 99,999999999 %. Die öffentliche Statusseite von GitHub behauptete die ganze Zeit über über 99 %. Diese Lücke zwischen dem, was auf der Statusseite reports steht, und dem, was Entwickler tatsächlich erlebt haben, untergräbt das Vertrauen schneller, als es ein einzelner Ausfall könnte.
Wenn der angesehenste Einzelentwickler in der Open-Source-Welt sagt, eine Plattform sei „kein Ort mehr für ernsthafte Arbeit“, müssen wir alle zumindest nachrechnen.
Was ich tatsächlich getestet habe (und das ehrliche Urteil)
Bevor ich mit dem Vergleich beginne, hier die Regel, die ich mir selbst gegeben habe: Ich würde keine Plattform anhand ihrer Marketingseite bewerten. Ich würde zu jedem ein echtes Projekt migrieren, meinen tatsächlichen workflow einen Tag lang damit laufen lassen und aufschreiben, was kaputt gegangen ist.
Das Projekt, das ich ausgewählt habe, war ein privates Laravel-Nebenprojekt mit etwa 240 Commits, GitHub-Aktionen für CI, zwei offenen PRs, drei Meilensteinen, zwölf Issues und einer CODEOWNERS-Datei. Kein Spielzeug. Auch kein 50.000-Sterne-Monster. Ungefähr die Form der Arbeit, die die meisten Leser dieser Website tatsächlich leisten.
Hier ist, was passiert ist.
GitLab: Die sichere Migration, die nicht ganz sicher ist
GitLab ist die offensichtliche erste Anlaufstelle. Es ist die Plattform, zu der jedes „GitHub alternatives 2026“-Listicle führt, und der Grund ist einfach: Es ist der einzige Konkurrent mit vergleichbarer Feature-Oberfläche. CI/CD, Problemverfolgung, Containerregistrierung, Paketregistrierung, Sicherheitsscans, alles gebündelt in einem Produkt, statt über GitHub-Aktionen, Pakete, Dependabot und erweiterte Sicherheit verteilt.
Ich habe das Laravel-Projekt mit dem integrierten GitHub-Importer auf GitLab.com (das SaaS, nicht selbst gehostet) migriert. Gesamtzeit vom Klicken auf „Importieren“ bis zum Anzeigen meines repo mit allen intakten PRs, Problemen und Meilensteinen: etwa elf Minuten. Der Importeur brachte mit:
- Vollständiger Git-Verlauf (offensichtlich)
- Probleme mit Beschriftungen und Meilensteinen
- Pull-Requests als Merge-Requests
- CI/CD-Konfiguration (mit Umschreibungen –
.github/workflows/*.ymlläuft nicht auf GitLab; Sie benötigen einen.gitlab-ci.yml) - Filialschutzregeln (manuell erneut angewendet)
- Webhooks (mussten neu erstellt werden)
Die CI-Neufassung war der eigentliche Kostenfaktor. Meine GitHub-Aktionen workflow führten PHPUnit aus, führten Pint zur Formatierung aus, führten einen statischen Analysedurchlauf über Larastan durch und stellten eine Vorschauumgebung auf einem Hetzner VPS bereit. Die Übersetzung in GitLab CI hat mich etwa neunzig Minuten gekostet, vor allem, weil der services:-Block von Sie können nicht kopieren und einfügen; du musst nachdenken.
Das, was GitLab derzeit besser macht als GitHub, ist die First-Party-DevOps-Integration. Wenn Sie ein Startup sind, das eine Plattform für Code, CI, Container-Registrierung, Paket-Registrierung und Sicherheitsscans benötigt und diese sonst aus GitHub und drei anderen Anbietern zusammenstellen würde, ist GitLab die sauberere Wahl. Die All-in-One-Geschichte ist real.
Der Haken – und das ist der Haken, auf den niemand laut genug hinweist – ist, dass GitLab.com seinen eigenen erheblichen Ausfall im Jahr 2025 hatte und unter dem gleichen grundlegenden Skalierungsdruck läuft, den GitHub hat. Die Migration von einem großen SaaS-Git-Host zu einem anderen großen SaaS-Git-Host aus Angst um die Zuverlässigkeit ist, ehrlich gesagt, eine unvollständige Strategie. Sie haben Ihren Single Point of Failure geändert, nicht entfernt.
Die Version von GitLab, die das Zuverlässigkeitsproblem tatsächlich behebt, ist selbstgehostetes GitLab – entweder die kostenlose Community Edition oder die kostenpflichtige Premium-Stufe. Das ist ein anderes Gespräch. Das ist eine Aufgabe des Systemadministrators. Das ist ein Server, der Patches, Backups, ein SSL-Zertifikat, ein SMTP-Relay und ein Runbook für den Tag benötigt, an dem er um 2 Uhr morgens ausfällt. Wenn Sie alleine oder in einem kleinen Team arbeiten, überwiegt die Betriebssteuer in der Regel den Zuverlässigkeitsgewinn.
GitLab-Urteil: Ein echter GitHub-Konkurrent in Bezug auf Funktionen. Ein fragwürdiger GitHub-Konkurrent in Bezug auf Zuverlässigkeit, wenn Sie auf GitLab.com bleiben. Eine echte Zuverlässigkeit spielt sich nur ab, wenn Sie selbst hosten – und selbst hosten ist ein Job, kein Kontrollkästchen.
Codeberg: Der, der mich überrascht hat
Codeberg ist die Plattform, die ich voraussichtlich in zwanzig Minuten schließen würde. Ich habe den Test ernster genommen als alles andere, was ich bewertet habe.
Kurzer Kontext: Codeberg ist eine deutsche gemeinnützige Organisation, die eine Instanz von Forgejo betreibt, einem von der Community verwalteten Soft Fork von Gitea. Es gibt keine Investoren, keine Werbung, keine Unternehmens-Roadmap, keine oben aufgeschraubten AI-Funktionen, keinen „agentischen workflow“-Anstieg, der die Last künstlich aufbläht. Die Finanzierung erfolgt durch Spenden. Die Philosophie ist eindeutig: ein sicheres Zuhause für freie und Open-Source-Software zu sein. Es wird in der EU unter einer Stiftung gehostet, was zwar unauffällig, aber enorm wichtig ist, wenn Sie GDPR-Exposition haben.
Ich habe das Laravel-Projekt importiert – nun ja, eine öffentlich zugängliche Abzweigung davon. In den eigenen Bedingungen von Der Import dauerte etwa sieben Minuten. Die Benutzeroberfläche ist unverkennbar „GitHub circa 2018“ – und das meine ich als Kompliment. PR-Ansicht, Issue-Ansicht, Meilenstein-Ansicht, Codesuche, alles sofort lesbar. Keine AI-Vorschläge. Kein Copilot-Upsell. Kein „Erkundungs“-Feed, der Sie auf der Website halten soll.
Das CI-System von Forgejo, Forgejo Actions, ist API-kompatibel mit GitHub Actions. Mein .github/workflows/ci.yml lief mit zwei kleinen Änderungen: einem umbenannten Runner-Label und einer Aktion, die ich vom GitHub-Marktplatz abgerufen hatte, musste durch eine entsprechende Version ersetzt werden, die in der eigenen Aktionsregistrierung von Codeberg veröffentlicht wurde. Ungefähr fünfundvierzig Minuten Arbeit, um grün zu werden.
Hier ist der Teil, der mich aufhorchen ließ. In der Woche vom 23. bis 28. April, als GitHub sichtlich Probleme hatte, zeigte die Statusseite von Codeberg den normalen Betrieb aller Komponenten an. Das ist keine überhebliche Behauptung, sondern ein struktureller Vorteil. Codeberg ist kein Ziel für dieselben Botnets in derselben Größenordnung, wird nicht von derselben Agentenlast attackiert und versucht nicht, seine Infrastruktur um das 30-fache zu skalieren, um mit dem synthetischen Datenverkehr Schritt zu halten. Die Plattform ist klein genug, um in einer Weise zuverlässig zu bleiben, wie es die Giganten derzeit nicht tun.
Die ehrlichen Grenzen: Codeberg ist absichtlich nicht für proprietäre Closed-Source-Arbeiten gedacht. Die verfügbaren CI-Minuten sind konservativ, da jemand spendet, um sie aufrechtzuerhalten. Es gibt keinen sozialen Graphen im LinkedIn-Stil, der die Entdeckung vorantreibt. Wenn die Wachstumsstrategie Ihres Projekts von der „Trending“-Seite von GitHub abhängt, können Sie dies hier nicht reproduzieren.
Codeberg-Urteil: Wenn Sie Open-Source-Software insbesondere in der EU versenden, insbesondere als Einzelperson oder kleines Team, ist dies das am meisten unterschätzte Migrationsziel im Jahr 2026. Es ist kein GitHub-Ersatz. Es ist etwas Besseres in den spezifischen Dimensionen, in denen GitHub nicht mehr gut ist – leise, zuverlässig, im Besitz der Community, der es dient.
SourceHut: Der für den Ingenieur gebaute, der Sie wahrscheinlich nicht sind
SourceHut ist die Plattform mit der größten Meinung, die ich getestet habe. Drew DeVault baute es auf einer klaren These auf: Das meiste, was modernes Git-Hosting „leistungsstark“ macht, ist tatsächlich Lärm, und ein E-Mail-gesteuertes, JavaScript-freies workflow ist für ernsthafte Softwareentwicklung schneller als jede UI-lastige Alternative. Die Preisgestaltung beginnt kostenlos; Bezahlte Stufen kosten je nach Nutzung etwa 20–50 $/year.
Ich werde ehrlich zu dir sein. Ich habe das Laravel-Projekt importiert, den workflow einen Tag lang ausgeführt und etwa nach sechs Stunden aufgegeben.
Nicht weil SourceHut schlecht ist. Da SourceHut für einen workflow erstellt wurde, führe ich ihn eigentlich nicht aus. Die Codeüberprüfung auf SourceHut erfolgt über Mailinglisten und git send-email. Die Fehlerverfolgung erfolgt über einen bewusst spartanisch gehaltenen Tracker. CI läuft über builds.sr.ht und ist wirklich schnell und sauber. Aber das kulturelle Delta – der Wechsel von der PR-basierten Überprüfung zur Patch-per-E-Mail-Überprüfung – ist enorm. Linux-Kernel-Betreuer lieben es. Die meisten von uns, mich eingeschlossen, haben ein Jahrzehnt lang Muskelgedächtnis aufgebaut, indem sie auf einer Weboberfläche auf „Genehmigen“ geklickt haben.
Die Plattform selbst ist tadellos konstruiert. Jede Seite wird in deutlich weniger als einer Sekunde gerendert. Es gibt nirgendwo JavaScript. Die Transparenz des Betreuers über Infrastrukturkosten und -entscheidungen ist einzigartig in diesem Bereich. Wenn Sie zu den Entwicklern gehören, die mutt für E-Mails ausführen und eine UI-Schaltfläche als persönliche Beleidigung betrachten, ist SourceHut die Plattform, die Ihre Ästhetik endlich belohnt.
SourceHut-Urteil: Für die meisten Teams keine GitHub-Alternative. Ein anderes Paradigma für die spezielle Untergruppe von Entwicklern, die wirklich einen Patch per E-Mail workflows wünschen. Respektieren Sie die Philosophie, aber seien Sie ehrlich, ob Sie tatsächlich dieser Ingenieur sind.
Die Migrationsmathematik, die Ihnen niemand zeigt
An dieser Stelle möchte ich auf alle „Top-GitHub-Alternativen“-Listen eingehen, die Sie diese Woche gelesen haben.
Die meisten bleiben beim Funktionsvergleich stehen. Der Funktionsvergleich ist der einfache Teil. Der Funktionsvergleich erfasst nicht die tatsächlichen Kosten für den Austritt aus GitHub, und wenn Sie diese Kosten nicht ehrlich beziffern, werden Sie entweder migrieren, wenn Sie nicht sollten, oder bleiben, wenn Sie nicht sollten.
Hier ist die wahre Mathematik.
Was GitHub Ihnen über das Hosting hinaus tatsächlich bietet
Wenn Sie auf GitHub hosten, zahlen Sie nicht dafür, dass git push funktioniert. git push funktioniert auf einem 5-Dollar-VPS mit einem nackten repo und einem SSH-Schlüssel. Sie zahlen – explizit mit Abonnementgeldern, implizit mit Ihren Daten – für einen miteinander verbundenen Stapel von Diensten, von denen die meisten auf Codeberg, SourceHut oder sogar GitLab keinen Ersatz haben.
Discovery und Inbound-Mitwirkende. Die „Trending“-Seite, das Erkundungsdiagramm, der Social Proof von Stars und Forks, die GitHub-native Suche, die einen Fremden auf Ihr Projekt stoßen lässt – das sind enorme Geschäftsressourcen für jeden Open-Source-Betreuer, und sie migrieren nicht. Mitchell Hashimoto kann Ghostty von GitHub verschieben, da Ghostty bereits berühmt ist. Ein neues Projekt, das versucht, ein Publikum aufzubauen, kann das nicht.
CI/CD Allgegenwärtigkeit. GitHub Actions ist zum De-facto-Bereitstellungsintegrationsziel für jeden Cloud-Anbieter, jede Paketregistrierung und jedes Release-Tool geworden. AWS veröffentlicht Aktionen. Cloudflare veröffentlicht Aktionen. Vercel veröffentlicht Aktionen. Die Replikation dieser Integrationsoberfläche an anderer Stelle ist nicht unmöglich, aber selten schlüsselfertig.
Das Marktplatz-Ökosystem. Aktionen von Drittanbietern, GitHub Apps, die Integrationsebene – nichts davon ist anderswo in der gleichen Dichte vorhanden. Wenn Ihr workflow von fünf Marktplatzaktionen abhängt, bedeutet die Migration, dass fünf Integrationen neu erstellt oder ersetzt werden.
Recruiting und Identität. Ihr GitHub-Profil ist für viele Unternehmen Ihr Lebenslauf. Ihr Beitragsdiagramm ist ein Ausweis. Ihr Benutzername ist eine Marke. Nichts davon lässt sich sauber auf eine neue Plattform übertragen – und der Netzwerkeffekt fließt nur in eine Richtung.
Das Migrationskosten-Arbeitsblatt
Hier ist das Arbeitsblatt, das ich gerne am Sonntagmorgen gehabt hätte. Führen Sie Ihr Projekt durch, bevor Sie eine Entscheidung treffen.
1. Repo-Migrationszeit. Für ein Projekt mit weniger als 500 Commits und Standardproblemen/PRs: ~30 Minuten pro repo allein für den Import. Multiplizieren Sie mit Ihrer repo-Anzahl.
2. CI-Umschreibezeit. GitHub-Aktionen für Forgejo-Aktionen auf Codeberg: Budget 30–90 Minuten pro workflow. GitHub-Aktionen für SourceHut-Builds: Planen Sie einen halben Tag pro workflow ein, wenn Sie noch nie zuvor einen geschrieben haben.
3. Neuverkabelung von Webhook und Integration. Jeder externe Dienst, der auf Ihrem repo postet (Slack, Discord, Bereitstellungs-Hooks, Statusprüfungen), muss neu konfiguriert werden. Planen Sie 15 Minuten pro Integration ein, mehr, wenn das Webhook-Format der neuen Plattform anders ist.
4. Zweigstellenschutz und Teamberechtigungen. Nichts davon wird automatisch migriert. Prüfen und neu erstellen. Planen Sie etwa 2 Stunden für einen typischen Teamaufbau ein.
5. Dokumentationsaktualisierungen. Jedes README-Abzeichen, jeder Wiki-Link, jedes externe Dokument mit der Aufschrift „Finden Sie uns auf GitHub.“ Das ist eine unscheinbare Arbeit, die länger dauert, als Sie denken.
6. Die Mitwirkendenkosten. Wenn Sie externe Mitwirkende haben, müssen diese ebenfalls migrieren. Manche werden das nicht tun. Sie werden mindestens im ersten Quartal nach der Migration etwas an Geschwindigkeit bei der Mitwirkenden verlieren. Berücksichtigen Sie das bei Ihrer Entscheidung.
7. Die Rekrutierungs- und Sichtbarkeitskosten. Wenn Ihr Projekt durch Entdeckung Mitwirkende gewinnt, ist der Netzwerkeffekt von GitHub Teil Ihrer Wachstumsstrategie. Das Verlassen bedeutet, dass die Pipeline an einem Ort mit schwächeren Netzwerkeffekten neu aufgebaut wird.
Für mein vierzig repo persönliches /work-Setup belief sich meine ehrliche Schätzung, GitHub vollständig zu verlassen, auf ungefähr 60 Stunden konzentrierte technische Arbeit plus eine mehrmonatige Reihe kleiner Korrekturen. Das ist eine reelle Zahl. Ein bedeutender Bruchteil der Produktivität eines Quartals, der gegen ein unbekanntes Maß an Zukunftssicherheit eingetauscht wird.
Multiplizieren Sie dies für ein Startup mit zwanzig Ingenieuren mit der Anzahl der repos und Integrationen, und Sie haben ein monatelanges Projekt mit echten Opportunitätskosten vor sich. Für ein öffentliches Projekt mit 50.000 Stars wie
Für die meisten Leser dieses Beitrags gilt: Die Migrationskosten sind höher als die Zuverlässigkeitskosten für die Aufrechterhaltung der Wiederherstellung von GitHub, es sei denn, eine von drei spezifischen Bedingungen ist erfüllt.
Wann Sie tatsächlich migrieren sollten (und wann nicht)
Nachdem ich die Berechnungen mit echtem workflows durchgeführt habe, ist hier das Framework, das ich persönlich verwende und Kunden empfehle.
Jetzt migrieren, wenn:
Ihre Arbeit hängt von der Korrektheit der Zusammenführungswarteschlange für den Hochgeschwindigkeits-monorepos ab. Der Vorfall vom 23. April hat insbesondere die Commit-Korrektheit in Warteschlangen beeinträchtigt. Wenn Ihr Team Dutzende von PRs pro Tag über automatisierte Warteschlangen zusammenführt und Sie nicht einmal eine geringe Wahrscheinlichkeit stiller Zurücksetzungen tolerieren können, ist die Vertrauenslücke zu groß, um abzuwarten. Die Merge-Trains von GitLab oder eine selbst gehostete Alternative sind sinnvolle Absicherungen.
Sie haben GDPR-Anforderungen oder EU-Datensouveränitätsanforderungen und Sie haben „GitHub ist dafür in Ordnung“ als eine funktionierende Annahme betrachtet, die Sie nicht wirklich geprüft haben. Codeberg oder selbst gehostetes Forgejo zur EU-Infrastruktur verdeutlicht Ihre Compliance-Geschichte auf eine Weise, die GitHub jetzt aktiv komplizierter macht.
Sie führen GitHub Enterprise Server aus. Dies ist der Punkt, bei dem Sie meiner Meinung nach heute und nicht im nächsten Quartal handeln sollten. CVE-2026-3854 betraf zum Zeitpunkt der Offenlegung schätzungsweise 88 % der GHES-Fälle. Wenn Sie noch nicht auf GHES 3.19.3 oder höher aktualisiert haben, ist dies Ihr erster Schritt, unabhängig von etwaigen Migrationsfragen. Die RCE-Kette – einen gefälschten rails_env einschleusen, das Hook-Verzeichnis umleiten, einen Pre-Receive-Hook einbauen, Codeausführung als Git-Benutzer erhalten – ist so einfach, dass die Ausnutzung in freier Wildbahn eine Frage des Zeitpunkts und nicht des Ob ist.
Bleiben Sie (mit Anpassungen), wenn:
Sie sind ein Einzelentwickler oder ein kleines Team, das aus Gründen der Sichtbarkeit das standardmäßige PR-basierte workflows auf dem öffentlichen repos ausführt. Die Migrationskosten sind real, die Entdeckungskosten hoch und die meisten der jüngsten Fehler von GitHub haben Git selbst nicht wirklich kaputt gemacht. Sie haben die UI-Ebene zerstört, die Ihre Arbeit findet. Der richtige Schritt besteht darin, sich gegen Ausfälle der UI-Ebene abzusichern (verwenden Sie gh
Ihr Unternehmen ist auf GitHub-native Integrationen wie Copilot, Advanced Security oder bestimmte Marktplatzaktionen angewiesen, die Sie nicht einfach ersetzen können. Wenn man ehrlich gesagt den Integrationsverlust bepreist, wird „migrieren“ oft zu „noch nicht“.
Sie betreiben ein Projekt, dessen Wachstum von der Erkennung eingehender Mitwirkender abhängt. Sie nutzen den Netzwerkeffekt von GitHub, auch wenn Sie das nicht so sehen. Unterschätzen Sie es nicht.
Das Hybridstück, das ich gerade mache
Für meine eigene Arbeit migriere ich nicht. Ich spiegele. Jeder wichtige repo von mir verfügt jetzt über einen automatischen Nachtspiegel für ein privates Codeberg-Konto. Wenn GitHub eine weitere schlechte Woche hat, habe ich eine funktionierende zweite Kopie. Wenn GitHub nie wieder eine schlechte Woche hat, habe ich etwa drei Stunden mit der Spiegelautomatisierung verbracht und mir ein Backup außerhalb der Plattform gesichert, das ohnehin eine gute Übung ist.
Das Setup besteht aus etwa dreißig Zeilen Bash plus einem Cron-Job. Codeberg akzeptiert Pushs von jedem Standard-Git-Client, sodass die Spiegelkonfiguration mit der aller anderen Remote-Clients identisch ist. Ich verwende git push --mirror nach einem Zeitplan, mit Anmeldeinformationen in einem separaten Tresor von meinen GitHub-Anmeldeinformationen. Das Ganze ist die Art von Redundanz mit geringem Einsatz, die Sie sich gewünscht hätten, bevor Sie sie brauchten. (Wenn Sie bereits in einen Claude Code workflow für terminalgesteuerte Entwicklung investiert haben, ist die Verkabelung als geplanter Hintergrundjob eine 20-minütige Aufgabe.)
Was dies über die Entwicklung der Entwicklerinfrastruktur aussagt
Ich möchte mit dem Teil abschließen, der größer ist als jede einzelne Plattform.
Der CTO von Dieser Satz ist mir die ganze Woche in Erinnerung geblieben. Er hat nicht Unrecht. Jeder Claude Code-Agent, jede Codex-Ausführung, jeder Cursor-Hintergrundjob, jede autonome Pipeline, die Sie und ich im Jahr 2026 ausführen, trifft GitHubs API stärker, als es ein Mensch jemals tun würde. Wir sind gemeinsam und zufällig die Last, die es kaputt gemacht hat.
Die Architektur, die GitHub im Jahr 2024 betrieb, war für menschliche Entwickler ausgelegt. Die im Jahr 2026 benötigte Architektur ist auf Agenten und Menschen ausgelegt, und die Lücke zwischen diesen beiden Zahlen beträgt ungefähr das 30-fache. Das ist das Skalierungsziel, zu dem sich das Unternehmen nun öffentlich bekannt hat. Es ist ein riesiges Ingenieursprojekt. Ob sie es in zwölf oder sechsunddreißig Monaten erreichen, ist die eigentliche Frage, die darüber entscheidet, ob die Vorfälle vom April 2026 ein vorübergehender Schmerzpunkt oder der Beginn eines längeren Rückgangs waren.
Was auch stimmt, ist, dass der gleiche Agenten-workflow-Anstieg, der die Lastkurve von GitHub verändert, verändert, was Entwickler an einem Git-Host schätzen. Uns liegt mehr an der Zuverlässigkeit von Codeberg und SourceHut wurden zufällig oder absichtlich für diese Zielgruppe entwickelt, Jahre bevor die Zielgruppe in großem Maßstab existierte. Ihr Moment ist jetzt. Wenn Sie AI-Agenten erstellen, die kontinuierlich auf APIs der Versionskontrolle zugreifen, ist die Auswahl des Hosts eine tragende Entscheidung in einer Weise, wie es vor zwei Jahren noch nicht der Fall war.
Nach dieser Woche bin ich mir am sichersten: Die Ära, in der „GitHub“ ein Synonym für „wo Code lebt“ war, geht zu Ende. Nicht weil GitHub zusammenbricht – Microsoft hat das Kapital, die Ingenieure und die strategischen Gründe, um das Problem zu beheben. Aber weil die Annahme der Unvermeidlichkeit verschwunden ist. Wir haben beobachtet, wie der bekannteste Einzelentwickler im Open-Source-Bereich einpackte und ging. Wir haben beobachtet, wie das Unternehmen selbst öffentlich zugab, dass seine Betriebszeit unter 86 % liegt. Der Standard ist geknackt, und ein geknackter Standard ist eine andere Art von Standard.
Du musst nicht gehen. Ich gehe nicht. Aber keiner von uns kann mehr davon ausgehen, dass GitHub die einzige ernsthafte Option für das Hosting von Code im Jahr 2026 ist. Die Frage steht endlich wieder auf dem Tisch – und das hat sich in diesem Monat mehr als jeder einzelne Vorfall geändert.
Hier also die Hausaufgabe. Stellen Sie irgendwann in den nächsten sieben Tagen einen einstündigen Timer ein. Wählen Sie das Arbeitsblatt von früher in diesem Beitrag aus. Führen Sie es mit einem Ihrer Projekte durch, das wirklich wichtig ist. Nur einer. Finden Sie heraus, wie hoch die tatsächlichen Migrationskosten für Sie sein würden, für Ihren Code, mit Ihren Integrationen.
Du wirst wahrscheinlich nicht umziehen. Aber Sie werden nie wieder in die Situation geraten, diese Entscheidung unter Panikbedingungen treffen zu müssen, wie es die Hälfte der technischen Manager, mit denen ich diese Woche gesprochen habe, letztendlich getan hat. Das ist der wahre Gewinn. Nicht die Migration. Die Klarheit.
Häufig gestellte Fragen
Ist GitHub gerade nicht erreichbar?
XQPLACEHolder27 Bestimmte Vorfälle am 23. April (Beschädigung der Zusammenführungswarteschlange) und am 27. April (Ausfall der Elasticsearch-Suche) führten zu mehrstündigen Unterbrechungen. Den Echtzeitstatus finden Sie auf den Monitoren von Drittanbietern und nicht auf der offiziellen Statusseite.
Ist GitLab tatsächlich zuverlässiger als GitHub?
Nicht kategorisch. GitLab.com läuft mit dem gleichen SaaS-Skalierungsdruck wie GitHub und hatte im Jahr 2025 eigene erhebliche Ausfälle. GitLab ist nur dann zuverlässiger als GitHub, wenn Sie es selbst hosten, wodurch Zuverlässigkeitsgewinne gegen die Betriebskosten für den Betrieb Ihres eigenen Servers eingetauscht werden. Für die meisten Teams löst der Wechsel des SaaS-Anbieters nicht die zugrunde liegende Zuverlässigkeitsfrage.
Was ist Codeberg und ist es eine echte GitHub-Alternative?
Codeberg ist eine deutsche gemeinnützige Organisation, die Forgejo betreibt, eine von der Community verwaltete Git-Plattform. Es ist eine echte Alternative für kostenlose und Open-Source-Projekte, insbesondere im Hinblick auf die Anforderungen der EU an die Datensouveränität. Es ist absichtlich nicht für proprietäre Closed-Source-Arbeiten geeignet. CI ist API-kompatibel mit GitHub-Aktionen und die Plattform blieb während der GitHub-Vorfälle im April 2026 voll funktionsfähig.
Sollte ich meinen privaten repos jetzt von GitHub migrieren?
Wahrscheinlich nicht, es sei denn, Sie fallen in eine von drei Kategorien: Hochgeschwindigkeits-Monorepos, abhängig von der Richtigkeit der Zusammenführungswarteschlange, GDPR/EU Souveränitätsanforderungen oder GitHub Enterprise Server-Instanzen, die CVE-2026-3854 noch nicht gepatcht haben. Für die meisten Einzelentwickler und kleinen Teams überwiegen die Migrationskosten die aktuellen Kosten für die Zuverlässigkeit. Ein intelligenterer Zwischenschritt ist die Spiegelung kritischer repos auf einen zweiten Host als Cold-Backup.
Was ist CVE-2026-3854 und betrifft es mich?
CVE-2026-3854 ist eine von Wiz Research am 28. April 2026 offengelegte Sicherheitslücke in CVSS 8.7 zur Remotecodeausführung, die von jedem authentifizierten Benutzer über einen einzigen git push mit manipulierten Push-Optionen ausgenutzt werden kann. GitHub.com wurde im März 2026 gepatcht – für Cloud-Benutzer sind keine Maßnahmen erforderlich. GitHub Enterprise Server-Benutzer müssen auf GHES 3.19.3 oder höher aktualisieren; Schätzungsweise 88 % der GHES-Instanzen waren zum Zeitpunkt der Offenlegung noch anfällig.
Lasst uns zusammenarbeiten
Möchten Sie AI-Systeme aufbauen, workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.
- Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Unternehmenslösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
