GitHub er nede igen: Mirrors, alternativer og hvordan du holder dig online

Hvis du for nylig har prøvet at pushe en branch, køre en CI-pipeline eller installere en pakke og mødt en fejlside, var du ikke alene. GitHub har haft flere afbrydelser og forringelser end normalt på det seneste, og for en platform i centrum for moderne softwareudvikling mærker hele branchen hver minut Downtime.

Dette indlæg er ikke et angreb. Før alt andet er det en tak. Og derefter, fordi vi alle stadig har arbejde at levere, en praktisk guide til GitHub-alternativer, Git Mirrors og hvordan du sikrer, at næste afbrydelse ikke stopper dit projekt — eller går ubemærket hen for dine brugere.

Tak, GitHub

Det er let at glemme, hvor meget én platform har ændret. GitHub gjorde kodehosting til et fællesskab og har i næsten to årtier været standardhjemmet for open source. Noget af det, vi i dag tager for givet:

• Pull requests og social code review — den workflow, en hel udviklergeneration lærte på GitHub.
• Et hjem for millioner af projekter — fra weekendeksperimenter til internettets infrastruktur.
• GitHub Actions, Pages og Packages — en komplet toolchain, der fik små teams til at føle sig kæmpestore.
• Netværkseffekter — stjerner, issues, diskussioner og README-kultur, der gjorde det en fornøjelse at opdage software.

Ingen af det forsvinder på grund af nogle få dårlige dage. Nedbrud rammer alle; jo mere succesfuld en platform er, desto flere mærker dens dårlige dag. Den sunde reaktion er ikke vrede. Det er taknemmelighed — plus en backup-plan. Og ærligt talt gør GitHub det let at følge sine dårlige dage via sin egen statusside. Men du burde ikke selv skulle tjekke den.

Hvad går egentlig i stykker, når GitHub er nede

github.com har en dårlig dag, er nedslagsfeltet større, end du tror:

• Clone, push og pull requests — dagligdagens grundfunktioner stopper.
• CI/CD-pipelines (Actions) — builds sættes i kø eller fejler, releases forsinkes.
• GitHub Pages — dokumentations- og marketingsider bliver sorte.
• Pakkeinstallationer — afhængigheder, der henter fra GitHub-endpoints, begynder at fejle.
• Webhooks og integrationer — events forsinkes eller går tabt og bryder stille automatisering.

Hvis din release-proces, din dokumentation eller dit produkt rører ved en af disse, er din Uptime nu koblet til GitHub's Uptime. Det er en risiko, du reelt kan reducere.

Git Mirrors: Din første forsvarslinje

Et Git Mirror er en komplet, løbende opdateret kopi af dit repository på en anden host. Et mirror er ikke en migration eller en protest — det er redundans. Når GitHub har en dårlig dag, lever din historik, dine branches og tags et andet sted.

1. Vælg et andet hjem. GitLab, Codeberg eller en self-hosted Gitea eller Forgejo fungerer alle rigtig godt.
2. Push alt én gang: klon med git clone --mirror, kør derefter git push --mirror mod den nye remote.
3. Hold det synkroniseret: tilføj enten en ekstra remote (git remote add mirror <url>) og push til begge, eller kør git push --mirror fra et planlagt job — en cron-entry hver time er nok for de fleste teams.
4. Eller lad kopien vedligeholde sig selv: GitLab, Gitea og Forgejo kan oprette pull-mirrors fra GitHub efter en tidsplan, uden cron.
5. Verificér spejlet lejlighedsvis. Et mirror, du aldrig tester, er en falsk tryghedsfølelse.

Et mirror giver dig ikke en ekstra CI eller issue-sporing, men det beskytter det mest værdifulde, du ejer: din kode og dens historik.

GitHub-alternativer, der er værd at kende

Du behøver ikke forlade GitHub for at være forberedt på en regnvejrsdag. At kende alternativerne — og måske holde et mirror på en af dem — er bare god ingeniørkunst. Hver af disse platforme har tjent reel tillid fra fællesskabet:

• GitLab — en komplet DevOps-platform med indbygget CI/CD, container registry og førsteklasses repository-mirroring i begge retninger. Den mest naturlige plan B for teams.
• Codeberg — en nonprofit-platform drevet af fællesskabet, baseret på Forgejo. Et reelt uafhængigt hjem for fri og open source-software.
• Sourcehut — minimalistisk, hurtig og e-mail-drevet. En forfriskende nøgtern tilgang til forge-værktøj.
• Gitea og Forgejo — lette open source-forges, du kan self-hoste. Fuld kontrol, lille aftryk, indbygget mirror-understøttelse.
• Bitbucket — den veletablerede Atlassian-mulighed med dyb Jira-integration.

Målet er ikke at forlade GitHub. Det er at kunne sige med god samvittighed, at man aldrig var helt afhængig af det.

Adskil, hvad du kan

Mirrors beskytter din kode. Men Downtime gør mest ondt, når alt andet hænger på samme host. Fordel belastningen:

• Dokumentation og landing pages — servér dem ikke kun fra GitHub Pages. Host dem som de produktionssider, de er.
• Pakker — publicér til mere end ét registry, fx npm plus et privat registry eller en anden platform.
• Releases — opbevar artefakter på dit eget storage eller CDN ud over GitHub Releases.
• CI — en ekstra pipeline på GitLab eller dine egne runners kan træde til, når Actions er nede.
• Badges og dybe links — hvis din README eller dit website refererer til raw.githubusercontent.com, så behandl den URL som en afhængighed og overvåg den som sådan.

Vid det, før dine brugere gør

At høre om et nedbrud via sociale medier betyder, at du kom for sent. Løsningen er kedelig og effektiv: overvåg de ting, du er afhængig af — GitHub selv, din Pages-side, dine clone-endpoints og selvfølgelig dit eget produkt.

Det er præcis derfor, vi byggede isthisthing.online. Tilføj HTTP-, TCP- eller ping-Monitors for hvert hop mellem dig og dine brugere: github.com, api.github.com, din GitHub Pages-URL og dine produktionsendpoints. Checks kører fra op til 10 globale lokationer i intervaller ned til 30 sekunder, og alerts lander i Slack, Microsoft Teams, Discord eller hvor som helst via Webhooks i det øjeblik, noget forringes.

Når GitHub er nede, fortæller din Monitoring dig inden for sekunder, om det er GitHub eller din egen stack — så skifter du til dit mirror, drejer en DNS-post eller holder blot op med at debugge en andens nedbrud.

Og når den dårlige dag er din, holder en automatisk opdateret Status Page dine brugere informeret i stedet for at lade dem opdatere din support-indbakke.

En praktisk resiliens-checkliste

1. Opret et mirror af hvert kritisk repository og hold det synkroniseret.
2. Tilføj en ekstra CI-pipeline til dine vigtigste projekter.
3. Publicér pakker og release-artefakter på mere end ét sted.
4. Host ikke dokumentation og marketingsider på én enkelt platform.
5. Overvåg github.com, api.github.com, dine Pages-URL'er og dine egne endpoints med hurtige Checks.
6. Rout alerts til Slack, Teams eller Discord, så de rigtige personer hører det først.
7. Publicér en offentlig Status Page, så dine brugere aldrig skal gætte.
8. Øv failover én gang, før du rent faktisk har brug for det.

GitHub har opbygget årtiers goodwill, og nogle få nedbrud ændrer ikke ved det. Forbliv taknemmelig, forbliv spejlet — og forbliv overvåget.

Klar til næste nedbrud? Opret din gratis isthisthing.online-konto og gør næste GitHub-hip til en fem minutters pause i stedet for en tabt eftermiddag.