GitHub è di nuovo giù: Mirror, alternative e come restare online

Se di recente hai provato a fare push di un branch, a lanciare una pipeline CI o a installare un pacchetto trovando una pagina di errore, non eri solo. GitHub ha avuto ultimamente più disservizi e rallentamenti del solito, e per una piattaforma al centro dello sviluppo software moderno, ogni minuto di Downtime si fa sentire in tutto il settore.

Questo articolo non è una requisitoria. Prima di tutto è un ringraziamento. E poi, perché abbiamo tutti ancora lavoro da pubblicare, una guida pratica alle alternative a GitHub, ai Git Mirror e a come fare in modo che il prossimo disservizio non fermi il tuo progetto — e non passi inosservato ai tuoi utenti.

Grazie, GitHub

È facile dimenticare quanto ha cambiato le cose una sola piattaforma. GitHub ha trasformato l'hosting di codice in una community e, da quasi vent'anni, è la casa predefinita dell'open source. Qualcosa che oggi diamo per scontato:

• Pull request e code review social — il workflow che un'intera generazione di sviluppatori ha imparato su GitHub.
• Una casa per milioni di progetti — dagli esperimenti del weekend all'infrastruttura di internet.
• GitHub Actions, Pages e Packages — una toolchain completa che faceva sembrare enormi i piccoli team.
• Effetti di rete — le stelle, le issue, le discussioni e la cultura del README che rendevano piacevole scoprire software.

Nulla di tutto questo sparisce per qualche brutta giornata. I disservizi capitano a tutti; più una piattaforma ha successo, più il mondo intero sente la sua giornata storta. La reazione sana non è la rabbia. È la gratitudine — più un piano B. E sinceramente, GitHub rende facile seguire le proprie giornate no attraverso la pagina di stato dedicata. Ma non dovresti doverla controllare tu.

Cosa si rompe davvero quando GitHub va giù

github.com ha una brutta giornata, il raggio d'azione è più grande di quanto pensi:

• Clone, push e pull request — le basi quotidiane si fermano.
• Pipeline CI/CD (Actions) — le build si accumulano o falliscono, le release slittano.
• GitHub Pages — i siti di documentazione e marketing vanno in buio.
• Installazione dei pacchetti — le dipendenze che scaricano da endpoint GitHub iniziano a fallire.
• Webhook e integrazioni — gli eventi arrivano in ritardo o si perdono, rompendo silenziosamente le automazioni.

Se il tuo processo di release, la tua documentazione o il tuo prodotto toccano uno di questi punti, la tua Uptime è ormai accoppiata a quella di GitHub. È un rischio che puoi davvero ridurre.

I Git Mirror: la tua prima linea di difesa

Un Git Mirror è una copia completa e aggiornata di continuo del tuo repository su un altro host. Un mirror non è una migrazione né una protesta — è ridondanza. Quando GitHub ha una brutta giornata, la tua cronologia, i tuoi branch e i tuoi tag vivono altrove.

1. Scegli una seconda casa. GitLab, Codeberg o un Gitea o Forgejo self-hosted funzionano benissimo.
2. Pusha tutto una volta: clona con git clone --mirror, poi esegui git push --mirror verso il nuovo remote.
3. Tienilo sincronizzato: oppure aggiungi un secondo remote (git remote add mirror <url>) e pusha su entrambi, o esegui git push --mirror da un job schedulato — una voce cron ogni ora basta per la maggior parte dei team.
4. O lascia che sia la copia a mantenere se stessa: GitLab, Gitea e Forgejo possono creare pull-mirror da GitHub su schedule, senza cron.
5. Verifica il mirror ogni tanto. Un mirror mai testato è una falsa sicurezza.

Un mirror non ti dà una seconda CI né un tracciamento delle issue, ma protegge la cosa più preziosa che possiedi: il tuo codice e la sua cronologia.

Le alternative a GitHub che vale la pena conoscere

Non devi lasciare GitHub per prepararti a una giornata di pioggia. Conoscere le alternative — e magari tenere un mirror su una di esse — è semplicemente buon engineering. Ognuna di queste piattaforme si è guadagnata una fiducia reale della community:

• GitLab — una piattaforma DevOps completa con CI/CD integrato, container registry e mirroring di repository di primo livello in entrambe le direzioni. Il piano B più naturale per i team.
• Codeberg — una piattaforma no-profit gestita dalla community, basata su Forgejo. Una casa davvero indipendente per il software libero e open source.
• Sourcehut — minimalista, veloce e orientato all'email. Un approccio rinfrescante e senza fronzoli ai forge.
• Gitea e Forgejo — forge open source leggere che puoi ospitare da solo. Controllo totale, impronta minima, supporto ai mirror integrato.
• Bitbucket — l'opzione storica di Atlassian con una profonda integrazione Jira.

L'obiettivo non è abbandonare GitHub. È poter dire, a viso aperto, di non esserne mai stati completamente dipendenti.

Disaccoppia ciò che puoi

I mirror proteggono il tuo codice. Ma il Downtime fa più male quando tutto il resto dipende dallo stesso host. Distribuisci il carico:

• Documentazione e landing page — non servirle solo da GitHub Pages. Ospitale come i siti di produzione che sono.
• Pacchetti — pubblica su più di un registry, per esempio npm più un registry privato o di una seconda piattaforma.
• Release — conserva gli artefatti sul tuo storage o CDN oltre alle GitHub Releases.
• CI — una seconda pipeline su GitLab o sui tuoi runner può subentrare quando Actions è giù.
• Badge e deep link — se il tuo README o il tuo sito riferiscono raw.githubusercontent.com, tratta quell'URL come una dipendenza e monitora come tale.

Sappilo prima dei tuoi utenti

Sapere di un disservizio dai social significa essere in ritardo. La soluzione è noiosa ma efficace: monitora le cose da cui dipendi — GitHub stesso, il tuo sito Pages, i tuoi endpoint di clone e naturalmente il tuo prodotto.

È esattamente per questo che abbiamo costruito isthisthing.online. Aggiungi Monitor HTTP, TCP o ping per ogni hop tra te e i tuoi utenti: github.com, api.github.com, il tuo URL GitHub Pages e i tuoi endpoint di produzione. I Check girano da fino a 10 località globali a intervalli fino a 30 secondi, e gli alert arrivano su Slack, Microsoft Teams, Discord o ovunque via Webhook nel momento in cui qualcosa si degrada.

Quando GitHub va giù, il tuo Monitoring ti dice in pochi secondi se è GitHub o il tuo stack — così passi al mirror, giri un record DNS o smetti semplicemente di debuggare il disservizio di qualcun altro.

E quando la brutta giornata è la tua, una Status Page aggiornata automaticamente tiene informati i tuoi utenti invece di lasciarli aggiornare la tua casella di supporto.

Una checklist pratica di resilienza

1. Crea un mirror di ogni repository critico e tienilo sincronizzato.
2. Aggiungi una seconda pipeline CI ai tuoi progetti più importanti.
3. Pubblica pacchetti e artefatti di release in più di un posto.
4. Non ospitare documentazione e pagine marketing su un'unica piattaforma.
5. Monitora github.com, api.github.com, i tuoi URL Pages e i tuoi endpoint con Check rapidi.
6. Instrada gli alert verso Slack, Teams o Discord così le persone giuste le sentono per prime.
7. Pubblica una Status Page pubblica così i tuoi utenti non devono mai indovinare.
8. Prova il failover una volta, prima di averne davvero bisogno.

GitHub si è costruito decenni di fiducia, e qualche disservizio non cambia questo. Resta riconoscente, resta in mirror e resta monitorato.

Pronto per il prossimo disservizio? Crea il tuo account isthisthing.online gratuito e trasforma il prossimo inciampo di GitHub in una pausa di cinque minuti invece che in un pomeriggio perso.