Ich komme zu einem der Lieblingsthemen, wenn es ums Ranten geht: Microsoft kauft irgend etwas auf, und verschlimmbessert das so lange, bis es definitiv kaputt ist. Scheint auch bei GitHub zu klappen, wenn meine Beobachtung stimmt. Die Ausfälle häufen sich, das GitHub-Team ist gefrustet und Microslop dengelt Copilot oben drauf. Am 23. April 2026 hat dann der "Fluch der bösen Tat" zugeschlagen und GitHub-Repositories nach dem Zufallsprinzip zerschossen.
GitHub hier im Blog
Ich nutze kein GitHub, bin also nicht über jeden Schluckauf der Plattform informiert. Aber ich bekomme schon mit, wenn was schief läuft. Seit der Übernahme von GitHub durch Microsoft im Jahr 2018 (siehe Microsofts GitHub-Deal: EU-Entscheidung am 19.10.2018) taucht die Plattform – meist durch Probleme – hier in Blog-Beiträgen auf (siehe Links am Artikelende). Und Microsofts Copilot-Spirenzchen lassen sich auch in Beiträgen verarbeiten.
Ein merkwürdiger Tweet wirft seinen Schatten
Es war der nachfolgende Tweet von Tom Warren, der mich neugierig werden ließ, was nun schon wieder auf GitHub los ist.
Im verlinkten The Verge-Kurzbeitrag schreibt Warren zum 24. April 2026, dass GitHub gerade einen massiven Ausfall hatte. Er ergänzt: GitHub nutzt eine Warteschlange für Entwickler, wenn viele Personen an einem einzigen Projekt arbeiten. Diese soll verhindern, dass Änderungen miteinander kollidieren und Entwickler Fehler verursachen. Doch gestern (war der 23. April) versagte diese Warteschlange aufgrund eines Fehlers auf katastrophale Weise. Zuvor zusammengeführte Commits (Code-Snapshots) wurden willkürlich rückgängig gemacht. Warren ergänzte: "GitHub hatte gestern auch weitere Ausfälle – genau an dem Tag, an dem ich über die Bedenken der Mitarbeiter hinsichtlich der Zuverlässigkeit und der Führung bei GitHub berichtet habe."
Das machte ich neugierig – im Textausriss des Tweets zitiert ein GitHub-Mitarbeiter, dass GitHub nicht mehr GitHub sei, sondern dass Microsoft drin stecke. Und das Unternehmen kollabiere derzeit, die Reputation der Plattform ginge den Bach runter. Weiterhin gebe es einen Exodus der Führungskräfte. Hört sich nicht so gut an – und mir fiel mein Blog-Beitrag Software Feedom Conservacy fordert Open Source-Entwickler zum Exit bei GitHub auf ein.
Der GitHub-Commit-Vorfall am 23. April 2026
Auf GitHub gibt es den Incident with Pull Requests-Beitrag. Dort heißt es: "Wir haben einen Regressionsfehler behoben, der bei der Verwendung der Merge-Warteschlange in Verbindung mit Squash-Merges oder Rebases auftrat. Wenn Sie die Merge-Warteschlange in dieser Konfiguration verwendet haben, wurden einige Pull-Anfragen zwischen dem 23.04.2026, 16:05 Uhr und 20:43 Uhr (UTC) möglicherweise nicht korrekt zusammengeführt. "
Sprich: Wer ein GitHub-Repository nutzt und Pull-Anfragen am 23.04.2026 zwischen 6:05 Uhr und 20:43 Uhr (UTC), dem wurde das Repository wohl mit hoher Wahrscheinlichkeit zerwürfelt. Auf dieser Hacker News-Seite wird das diskutiert – einige Teams hat es wohl erwischt und die bauen mühsam einen stimmigen Stand auf.
Ergänzung: Gergely Orosz beschreibt es auf X mit folgenden Worten:
A terrible incident coming from an infra provider. This is not an outage resulting in downtime, or data lost on the cloud (that is trivial to restore from local git.)
It's a data integrity issue, which sounds hard and difficult to untangle by anyone hit by it.
A real WTH moment
Müssen wir den Copilot ran lassen, um das zu fixen? Kyle Daigle, COO bei GitHub hat dann am 25. Apr. 2026 gegen 12:22 auf X die nachfolgende Erklärung zum Vorfall gepostet:
Wanted to provide more clarity about this.
Yesterday, we had a regression in merge queue behavior where, in some cases, squash or rebase commits were generated from the wrong base state, making earlier changes appear reverted in branch history. 2,804 pull requests out of over 4M merged on April 23 (roughly 0.07%) were affected. We fixed the issue, we've contacted every impacted customer, and we're expanding our automated test coverage for merge queue operations. The team will be updating the status page with RCA details as well.
Das eine Mal zu viel?
Um es klarzustellen, Fehler lassen sich wohl nie vermeiden. Aber es ergibt sich ein fatales Bild. Oben hatte ich Tom Warren zitiert, der mit einem GitHub-Angestellten sprach, der meinte, GitHub ist Microsoft und geht den Bach herunter. Dazu kommt die ständige Gängelei mit Copilot.
Auf reddit.com hat jemand die obige Grafik mit Ausfällen bei GitHub seit der Übernahme durch Microsoft gepostet. Da ist schon "Bewegung" drin. Auf X schreibt jemand etwas von "einer Verfügbarkeit von 87,87 % für eine der wichtigsten Infrastrukturkomponenten im Internet" und fragt: "Hat KI den gesamten Stack so anfällig gemacht?"
Wird es Zeit, GitHub zu verlassen, bevor das ganz kollabiert? Wie sehen das GitHub-Nutzer – alles nicht so wild, oder Götterdämmerung?
Ähnliche Artikel:
Microsofts GitHub-Deal: EU-Entscheidung am 19.10.2018
Github-Übernahme durch Microsoft–grünes Licht der EU
Microsoft kauft JavaScript-Entwickler-Plattform npm, GitHub-Integration kommt
Free Software Foundation hält Microsofts GitHub Copilot für unfair und nicht legal
Software Feedom Conservacy fordert Open Source-Entwickler zum Exit bei GitHub auf
Schwachstellen bei GitHub
Datenleck: Microsoft AI-Forscher verlieren 38 TByte an internen Daten über GitHub/Azure Cloud-Speicher
Microsoft "verbrennt" wohl massiv Geld mit GitHub-Copilot
Verlangt GitHub neuerdings eine Anmeldung?
GitHub trainiert Copilot mit Benutzerdaten; Opt-out erforderlich
Microsoft Copilot: Werbung in GitHub Pull-Requests
GitHub Copilot-Schwachstelle CVE-2025-59145 erlaubt Datenextraktion
Kritische Schwachstelle in Microsoft-GitHub-Repository
Microsoft stellt GitHub Copilot ab Juni 2026 auf "Token-based" Billing um
MVP: 2013 – 2016
"Diese soll verhindern, dass Änderungen miteinander kollidieren"
WTF? Wozu benutzt man nochmals Git?
Ich bin froh seit vielen Jahren bei Codeberg zu sein. Dort gibt es auch ab und an Aussetzer. Aber nicht von der Qualität wie bei GitHub. Und man muss immer bedenken, dass da Freiwillige und ein kleiner Verein viel und gute Arbeit leisten, kein Mrd-schwerer BigTech Konzern.
Tja da sind halt keine Aktionäre die die Kralle aufhalten… ;-P
Es geht hier um Squash und Rebase bitte beachten.
Kann nur zustimmen (seit Jahren Vereinsmitglied, wenngleich auch nur passiv zur finanziellen Unterstützung)
für mich WTF:
GitHub fängt an auch auf Benutzerseite mit der CLI Daten zu sammeln "Telemetrie"
ist standardmässig aktiv
(weil die wollen 'verstehen' wie die 'agentic adoption of GitHub CLI' genutzt wird)
github[.]blog / changelog / 2026-04-22-github-cli-opt-out-usage-telemetry
…
cli[.]github[.]com / telemetry
device_id (UUID) Random identifier generated once and stored locally per user/device combination (not a machine ID)
invocation_id (UUID) Random identifier generated once per gh invocation
die 'invocation_id' wäre noch 'akzeptabel'
'meine Fantasiererei':
mit / in Kombination der 'device_id' kann man auch schön sehen, was hinter firewall in einer Firma für Rechner/wie genutzt werden…,
und in Kombination mit dem Benutzer der da Repos pusht/pullt umfangreiches weiteres Profil…
YMMV
Ich schätze die wenigsten Projekte auf GitHub nutzen Merge Queues, Im Prinzip vertraut man da auch wenn alles funktioniert dem automatischen Rebase und den Checks. Wenn man nicht gerade sehr viele Pull Requests am Tag bekommt werden die meisten Projekte den klassischen Weg gehen: Rebase, test, push. und der Weg war nicht von den Problemen betroffen.
Soweit ich es gesehen habe, gab es Betroffene. Unabhängig davon sollte so was nicht passieren. Meinem Eindruck nach sond die Leute genervt von Problemen.
https://news.ycombinator.com/item?id=47885756
> 4 people spent hours putting our repo back together at my company after this.
In der Tat gab es Betroffene. Bei HN finden sich einige.
Das wollte ich auch nicht bestreiten. Es hilft nur nicht, den Leuten alternative Plattfomen nahezulegen, die das Feature gar nicht haben. Vorher RTFM, welches klar sagt, dass Merge Queues mit Risiken verbunden sind. Dass diese dann katastrophaler ausfallen als erwartet ist zugegebenermaßen unschön.
War bei Xeroxgate auch nicht anders wo verlustbehaftete JBIG PDFs plötzlich mehr und unscheinbareren Verlust hatten als man akzeptieren konnte.
Es beschwert sich ja auch niemand mehr dass KIs halluzinieren.
Mein Fazit: ich hatte Merge Queues immer gemieden und werde das auch weiterhin tun, solange ich ausreichend wenig zu mergen habe.
Mein Mitleid hält sich in Grenzen. Seit GitHub von Microslop übernommen wurde, ist offensichtlich wo die Reise hingeht.
Es ist wirklich nicht schwer selber ein GitLab oder Gitea zu hosten – erst recht nicht, wenn man professionell damit arbeiten will. Die Daten sind so sicher on-premise oder bei einem vertrauenswürdigen Hoster. Niemand kann deinen Code ungefragt zum Training für AI-Slop benutzen. Null Abhängigkeit von US-amerikanischen Großkonzernen. Kurz: Win-win-win!
Hab diverse Threads von anonym gelöscht, das dieses Thema entgleist ist.
Hilfreicher Kommentar falls betroffen unter https://news.ycombinator.com/item?id=47882283
> The window to audit is 2026-04-23 16:05 to 20:43 UTC, about 4h 38m, and 'merged incorrectly' is unpacked in exactly no detail on the status page. Practical check is to compare the tree of each merge commit in that window against the tree of the rebased-and-tested commit that the queue ran CI on. GitHub Enterprise Cloud with Data Residency is still affected as of the latest status update, so DR customers shouldn't clear new queue merges yet.
Ich dachte es heißt jetzt forgejo.org
Um ruhiger schlafen zu können
Viele werden, für einen Wechsel, einfach zu faul sein oder können "programmieren" bzw. Librarys und Frameworks zusammen kleben aber haben sonst von dem Thema keine Ahnung weil es zu kompliziert sei, es gibt doch KI.
"Für einen Wechsel zu Faul…" Ja, siehe zum Beispiel Google Maps.
"Es hilft nur nicht, den Leuten alternative Plattfomen nahezulegen, die das Feature gar nicht haben." Mh, Features die komfortabel sind, aber die man eigentlich nicht braucht…. Äh, wieder anschauliches Beispiel: siehe Google Maps.
Eine "Programm&App-Brutstätte" und Ein Handelsplatz für den wettvollsten Rohstoff der Gegenwart (nämlich Daten) in den Krallen eines milliardenschweren US-Konzern? nein Danke…
siehe leider auch wieder Google (und Apple schon lang): ab September 2026 Apps auf Android nur noch mit Identität/Personalausweis (und natürlich auch Lizenskosten)!
https://keepandroidopen.org/de/
Jeder, der die Zeichen der Zeit nicht erkennt und jetzt immer noch auf GitHub entwickelt, dem ist einfach nicht mehr zu helfen oder: der ist Teil des ganzen Übels!
Warum erkennen so viele die Gefahr des Locked-In-Syndrom erst, wenn das Kind fast schon in Brunnen gefallen ist? Es gibt nix für umsonst in der Marktwirtschaft!
enshittification at its best
Github Enterprise Server ist auch nicht viel besser. Unsere Firmeninstanz kämpft seit Monaten mit Performance-Problemen, dazu befindet sich diese auch auf der Migration nach Azure.
Der Code ist arg veraltet, die Aktion zum Artefakte hochladen ist bei GHES noch auf v3 beschränkt (auf Github.com seit November 2024 deprecated), weil die neueren nicht unterstützt werden.
Ich habe genügend Beschwerden über Github, das hier ist noch lange nicht alles.
Man merkt eben deutlich, daß Github inzwischen ein Microsoft Projekt ist. Genauso ist es mit der Zuverlässig aber auch mit dem ganzen Shit der dazu gekommen ist. Ich benutze eine eigene git Instanz, in meinem Falle gitea, und verwende Github als Backup. weil das Unternehmen das so will, auch wenn Github keine Pull-Mirrors unterstützt ich das ganze im Push machen muß. Codeberg bzw. Forgejo ist eine feine Sache, auch die Idee mit der Federation sehe ich positiv. Leider ist Codeberg die einzige Instanz und ich habe noch niemanden gefunden, der Forgejo managed als private Instanz anbietet.
In diesem Moment kann man doch dankbar sein, dass Linux keine Firma ist, die man kaufen kann.
Ich ärgere mich eigentlich immer über die 10 Millionen Distributionen am Markt und dass es für alles 10 verschiedene Programme gibt.
Ist dann vielleicht doch nicht so schlecht…